[Phpmyadmin-devel] View's default page in navigation tree
Hi, While looking at source code, I saw that the navigation tree icon for table depends of NavigationTreeDefaultTabTable configuration variable, but icon for view is always linked to tbl_structure.php. Does someone know why the view icon isn't linked with this variable please? Currently, there are 5 possible values for this configuration variable: * 'tbl_structure.php' = fields list * 'tbl_sql.php' = SQL form * 'tbl_select.php' = search page * 'tbl_change.php' = insert row page * 'sql.php' = browse page Maybe, one of them is not possible or not always (is "Insert row page" always accessible?). Looking at Sakila DB, it seems that, on a view, I can reach all these pages. Thanks for your help. Hugues.
Le 2015-01-11 10:12, Hugues Peccatte a écrit :
Hi,
While looking at source code, I saw that the navigation tree icon for table depends of NavigationTreeDefaultTabTable configuration variable, but icon for view is always linked to tbl_structure.php. Does someone know why the view icon isn't linked with this variable please?
Because the need to change the link target was never mentioned; also because the configuration variable's name is not NavigationTreeDefaultTabTableAndView.
Currently, there are 5 possible values for this configuration variable: * 'tbl_structure.php' = fields list * 'tbl_sql.php' = SQL form * 'tbl_select.php' = search page * 'tbl_change.php' = insert row page * 'sql.php' = browse page
By the way, using script names as values for such variables has always bothered me. I would prefer more neutral strings like 'search', 'structure' and so on. But this is a separate discussion.
Maybe, one of them is not possible or not always (is "Insert row page" always accessible?). Looking at Sakila DB, it seems that, on a view, I can reach all these pages.
Not all views are insertable; see http://dev.mysql.com/doc/refman/5.7/en/view-updatability.html. However, phpMyAdmin does not attempt to detect this when showing the menu tabs. -- Marc Delisle | phpMyAdmin
2015-01-12 11:55 GMT+01:00 Marc Delisle <marc@infomarc.info>:
Le 2015-01-11 10:12, Hugues Peccatte a écrit :
Hi,
While looking at source code, I saw that the navigation tree icon for table depends of NavigationTreeDefaultTabTable configuration variable, but icon for view is always linked to tbl_structure.php. Does someone know why the view icon isn't linked with this variable please?
Because the need to change the link target was never mentioned; also because the configuration variable's name is not NavigationTreeDefaultTabTableAndView.
Currently, there are 5 possible values for this configuration variable: * 'tbl_structure.php' = fields list * 'tbl_sql.php' = SQL form * 'tbl_select.php' = search page * 'tbl_change.php' = insert row page * 'sql.php' = browse page
By the way, using script names as values for such variables has always bothered me. I would prefer more neutral strings like 'search', 'structure' and so on. But this is a separate discussion.
Maybe, one of them is not possible or not always (is "Insert row page" always accessible?). Looking at Sakila DB, it seems that, on a view, I can reach all these pages.
Not all views are insertable; see http://dev.mysql.com/doc/refman/5.7/en/view-updatability.html. However, phpMyAdmin does not attempt to detect this when showing the menu tabs.
-- Marc Delisle | phpMyAdmin
Hi, Ok, thanks for your answer! I knew that some views weren't insertable/updatable (even without knowing the rules). But if pMA does not attempt to detect this, what do you think about using the same configuration variable to define link in navigation tree please? So this PR [1] could evolve to also apply to views. I agree that using the filenames is not a good think to me. I do not see how to update the config variable with new keyword values… [1] https://github.com/phpmyadmin/phpmyadmin/pull/1457 Hugues.
On 1/12/15, 5:55 AM, Marc Delisle wrote:
Le 2015-01-11 10:12, Hugues Peccatte a écrit :
...
NavigationTreeDefaultTabTableAndView.
Currently, there are 5 possible values for this configuration variable: * 'tbl_structure.php' = fields list * 'tbl_sql.php' = SQL form * 'tbl_select.php' = search page * 'tbl_change.php' = insert row page * 'sql.php' = browse page
By the way, using script names as values for such variables has always bothered me. I would prefer more neutral strings like 'search', 'structure' and so on. But this is a separate discussion.
Hi, This seems reasonable to me, though I wonder how we would handle the internationalization of the text. Would we force everyone to use the English tab names or their local language equivalent? If we use the local translated string, which seems reasonable to me if we're making the change, then we need some way to make sure the user puts here, for instance, Struktur instead of Zusammensetzung. I'm not sure that it will work well to write in the documentation "Use here the string text that appears as the link in the tabs across the top of the page, for instance in French use 'Structure' or in Italian 'Struttura'." Doing so would also break installations where one user uses English and another user prefers Tamil. The more I think about it with that in mind, the more I think we'd have to force everyone to use the English language link text. Is this worth doing? If so, I can work on it.
2015-01-12 16:07 GMT+01:00 Isaac Bennetch <bennetch@gmail.com>:
On 1/12/15, 5:55 AM, Marc Delisle wrote:
Le 2015-01-11 10:12, Hugues Peccatte a écrit :
...
NavigationTreeDefaultTabTableAndView.
Currently, there are 5 possible values for this configuration variable: * 'tbl_structure.php' = fields list * 'tbl_sql.php' = SQL form * 'tbl_select.php' = search page * 'tbl_change.php' = insert row page * 'sql.php' = browse page
By the way, using script names as values for such variables has always bothered me. I would prefer more neutral strings like 'search', 'structure' and so on. But this is a separate discussion.
Hi,
This seems reasonable to me, though I wonder how we would handle the internationalization of the text. Would we force everyone to use the English tab names or their local language equivalent? If we use the local translated string, which seems reasonable to me if we're making the change, then we need some way to make sure the user puts here, for instance, Struktur instead of Zusammensetzung. I'm not sure that it will work well to write in the documentation "Use here the string text that appears as the link in the tabs across the top of the page, for instance in French use 'Structure' or in Italian 'Struttura'." Doing so would also break installations where one user uses English and another user prefers Tamil.
The more I think about it with that in mind, the more I think we'd have to force everyone to use the English language link text.
Is this worth doing? If so, I can work on it.
Isaac, I'm not sure about what you said. Do we agree that the proposal is not to have a free text, but still a select with less technical terms? Hugues.
Hi, On 1/12/15, 3:33 PM, Hugues Peccatte wrote:
2015-01-12 16:07 GMT+01:00 Isaac Bennetch <bennetch@gmail.com <mailto:bennetch@gmail.com>>:
On 1/12/15, 5:55 AM, Marc Delisle wrote: > Le 2015-01-11 10:12, Hugues Peccatte a écrit : > ... > NavigationTreeDefaultTabTableAndView. >> >> Currently, there are 5 possible values for this configuration variable: >> * 'tbl_structure.php' = fields list >> * 'tbl_sql.php' = SQL form >> * 'tbl_select.php' = search page >> * 'tbl_change.php' = insert row page >> * 'sql.php' = browse page > > By the way, using script names as values for such variables has always > bothered me. I would prefer more neutral strings like 'search', > 'structure' and so on. But this is a separate discussion.
Hi,
This seems reasonable to me, though I wonder how we would handle the internationalization of the text. Would we force everyone to use the English tab names or their local language equivalent? If we use the local translated string, which seems reasonable to me if we're making the change, then we need some way to make sure the user puts here, for instance, Struktur instead of Zusammensetzung. I'm not sure that it will work well to write in the documentation "Use here the string text that appears as the link in the tabs across the top of the page, for instance in French use 'Structure' or in Italian 'Struttura'." Doing so would also break installations where one user uses English and another user prefers Tamil.
The more I think about it with that in mind, the more I think we'd have to force everyone to use the English language link text.
Is this worth doing? If so, I can work on it.
Isaac,
I'm not sure about what you said. Do we agree that the proposal is not to have a free text, but still a select with less technical terms?
Hugues.
I certainly didn't phrase it well, but also I think I was over-thinking it. I'll try again with my revised thoughts at the end. If I correctly understand what Marc wrote, instead of using the PHP file name I would use the name of the tab (or some other text), such as $cfg['NavigationTreeDefaultTabTable'] = 'Structure'; On the surface, this seemed like a great idea to me, we could simply match the name of the tabs (Browse, Structure, SQL, Search, and so on) instead of using the file names such as tbl_structure.php, tbl_select.php, and so on. Then it occurred to me that, thanks to our great local language support, *my* structure tab is called "Structure" but in Italian it's "Struttura" -- so we will have to standardize whatever text we use. My first thought was to just make the configuration options match the tab text, but that won't work due to the internationalization. We can't try to match the configuration file based on what text is displayed to the user. This is where I got stuck earlier today. Then I had some further thought. We do this all the time in the configuration. I mean, not this exactly, but $cfg['GridEditing'] can be 'click' 'double-click' or 'disabled' -- none of which change if the user is using a different language. Similarly with $cfg['DefaultDisplay'] and probably a dozen other configuration options; we force the user to set a value in English. This is not a bad thing, but is the part I had forgotten about when I sent out my earlier message. So yeah, I completely support this idea, and sorry for the noise while my thoughts hadn't fully formed. Writing them out and confusing you all is what it took to get me on the right path :) I've taken the liberty of opening a feature request about this: https://sourceforge.net/p/phpmyadmin/feature-requests/1594/
2015-01-13 7:05 GMT+01:00 Isaac Bennetch <bennetch@gmail.com>:
Hi,
On 1/12/15, 3:33 PM, Hugues Peccatte wrote:
2015-01-12 16:07 GMT+01:00 Isaac Bennetch <bennetch@gmail.com <mailto:bennetch@gmail.com>>:
On 1/12/15, 5:55 AM, Marc Delisle wrote: > Le 2015-01-11 10:12, Hugues Peccatte a écrit : > ... > NavigationTreeDefaultTabTableAndView. >> >> Currently, there are 5 possible values for this configuration variable: >> * 'tbl_structure.php' = fields list >> * 'tbl_sql.php' = SQL form >> * 'tbl_select.php' = search page >> * 'tbl_change.php' = insert row page >> * 'sql.php' = browse page > > By the way, using script names as values for such variables has always > bothered me. I would prefer more neutral strings like 'search', > 'structure' and so on. But this is a separate discussion.
Hi,
This seems reasonable to me, though I wonder how we would handle the internationalization of the text. Would we force everyone to use the English tab names or their local language equivalent? If we use the local translated string, which seems reasonable to me if we're making the change, then we need some way to make sure the user puts here, for instance, Struktur instead of Zusammensetzung. I'm not sure that it will work well to write in the documentation "Use here the string text that appears as the link in the tabs across the top of the page, for instance in French use 'Structure' or in Italian 'Struttura'." Doing so would also break installations where one user uses English and another user prefers Tamil.
The more I think about it with that in mind, the more I think we'd have to force everyone to use the English language link text.
Is this worth doing? If so, I can work on it.
Isaac,
I'm not sure about what you said. Do we agree that the proposal is not to have a free text, but still a select with less technical terms?
Hugues.
I certainly didn't phrase it well, but also I think I was over-thinking it. I'll try again with my revised thoughts at the end.
If I correctly understand what Marc wrote, instead of using the PHP file name I would use the name of the tab (or some other text), such as $cfg['NavigationTreeDefaultTabTable'] = 'Structure';
On the surface, this seemed like a great idea to me, we could simply match the name of the tabs (Browse, Structure, SQL, Search, and so on) instead of using the file names such as tbl_structure.php, tbl_select.php, and so on.
Then it occurred to me that, thanks to our great local language support, *my* structure tab is called "Structure" but in Italian it's "Struttura" -- so we will have to standardize whatever text we use. My first thought was to just make the configuration options match the tab text, but that won't work due to the internationalization. We can't try to match the configuration file based on what text is displayed to the user. This is where I got stuck earlier today.
Then I had some further thought. We do this all the time in the configuration. I mean, not this exactly, but $cfg['GridEditing'] can be 'click' 'double-click' or 'disabled' -- none of which change if the user is using a different language. Similarly with $cfg['DefaultDisplay'] and probably a dozen other configuration options; we force the user to set a value in English. This is not a bad thing, but is the part I had forgotten about when I sent out my earlier message.
So yeah, I completely support this idea, and sorry for the noise while my thoughts hadn't fully formed. Writing them out and confusing you all is what it took to get me on the right path :)
I've taken the liberty of opening a feature request about this: https://sourceforge.net/p/phpmyadmin/feature-requests/1594/
Isaac, Thanks for this complete answer. Now, I got it! And you're right. But it would be really hard to describe values if related to language. So as you said, English seems to be OK. Thanks for the ticket. Hugues.
2015-01-13 9:10 GMT+01:00 Hugues Peccatte <hugues.peccatte@gmail.com>:
Isaac,
Thanks for this complete answer. Now, I got it! And you're right. But it would be really hard to describe values if related to language. So as you said, English seems to be OK.
Thanks for the ticket.
Hugues.
Just to come back to the original question: if there is no reason not to use this configuration variable (except the name), can we use it for view's icon? Hugues.
participants (3)
-
Hugues Peccatte -
Isaac Bennetch -
Marc Delisle