[Phpmyadmin-devel] 'Insert data from a textfile into table' link place
Hello, At the end of the tbl_properties_structure.php3 page there is, when allowed, the * Insert data from a textfile into table link. It's a detail, but do you think it's the right place for this link? :) It has nothing to do with the table structure... Where could we move it ? "Export" has it's own tab, so "Import" would ne nice, and display the whole form generated by ldi_table.php3. But there are already too many tabs: maybe Export could be renamed to "Export/Import"? Other possibilty: move the link to the "Insert" page (would also be quite logical), or to the Operations page. What do you think? :) regards, Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland
Hi On Sunday 02 February 2003 17:18, Olivier M. wrote:
At the end of the tbl_properties_structure.php3 page there is, when allowed, the * Insert data from a textfile into table link.
It's a detail, but do you think it's the right place for this link? :) It has nothing to do with the table structure...
Indeed, I got few questions how to import text files, because people didn't find it there.
Where could we move it ? "Export" has it's own tab, so "Import" would ne nice, and display the whole form generated by ldi_table.php3. But there are already too many tabs: maybe Export could be renamed to "Export/Import"?
Other possibilty: move the link to the "Insert" page (would also be quite logical), or to the Operations page.
What do you think? :)
It is not on separate tab, because we have enough tabs now ;-). Export/Import name is long, it would b almost same. Even current layout won't fit on 800 pixels..... If you will find one (short) word for Export/Import tab.... Better would be to move Empty and Drop links (they are not used too much, and I see no reason why to have separate tabs for them) on Operations tab and add Import tab. How about that? -- Regards Michal Cihar nijel at users dot sourceforge dot net http://cihar.liten.cz
Hi!
It is not on separate tab, because we have enough tabs now ;-). Export/Import name is long, it would b almost same. Even current layout won't fit on 800 pixels..... If you will find one (short) word for Export/Import tab....
How about the term 'External'?
Better would be to move Empty and Drop links (they are not used too much, and I see no reason why to have separate tabs for them) on Operations tab and add Import tab. How about that?
Hm, I know of many people who've gotten used to those tabs -- including me and all people whom I instruct usage on phpMyAdmin. Otherwise I would like to see the insert-Link in the 'Insert' tab. Second chocice for me would be the 'Operations' tab. Regards, Garvin.
On Sun, Feb 02, 2003 at 06:33:22PM +0100, garvin_mailings@supergarv.de wrote:
It is not on separate tab, because we have enough tabs now ;-). Export/Import name is long, it would b almost same. Even current layout won't fit on 800 pixels..... If you will find one (short) word for Export/Import tab....
How about the term 'External'?
It first made me think about my HP48 and the sysrpl programmation based on "Externals" :) Would be an option, but "Import" and "Export" are probably much clearer, especially for non programmers.
Hm, I know of many people who've gotten used to those tabs -- including me and all people whom I instruct usage on phpMyAdmin.
ok...
Otherwise I would like to see the insert-Link in the 'Insert' tab. Second chocice for me would be the 'Operations' tab.
ok. Just noticed now that the link is also visible on the "SQL" (tbl_properties.php3) tab: maybe also not the best place (has nothing to do with 'sql' itself). Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
Hi!
How about the term 'External'?
It first made me think about my HP48 and the sysrpl programmation based on "Externals" :) Would be an option, but "Import" and "Export" are probably much clearer, especially for non programmers.
True...How about "Files" then? :-)
Hm, I know of many people who've gotten used to those tabs -- including me and all people whom I instruct usage on phpMyAdmin.
ok...
I know they are a waste, but many users of phpMyAdmin like the non-cluttered "main page" ('tbl_properties_structure') view, so that's where they use the "big alerting" labels. As I think about it, they mainly use the 'empty' button because most novice users won't drop a DB that often. Anyways, it might just be personal preference.
ok. Just noticed now that the link is also visible on the "SQL" (tbl_properties.php3) tab: maybe also not the best place (has nothing to do with 'sql' itself).
Funny thing, I never noticed it there. :) Garvin.
HI On Sunday 02 February 2003 22:53, garvin_mailings@supergarv.de wrote:
How about the term 'External'?
It first made me think about my HP48 and the sysrpl programmation based on "Externals" :) Would be an option, but "Import" and "Export" are probably much clearer, especially for non programmers.
True...How about "Files" then? :-)
That sounds better...
Hm, I know of many people who've gotten used to those tabs -- including me and all people whom I instruct usage on phpMyAdmin.
ok...
I know they are a waste, but many users of phpMyAdmin like the non-cluttered "main page" ('tbl_properties_structure') view, so that's where they use the "big alerting" labels. As I think about it, they mainly use the 'empty' button because most novice users won't drop a DB that often. Anyways, it might just be personal preference.
But now it's great time to do some more visible change in the interface, we will have new minor version ;-). I know that some didn't still get used to the tabs (see RFE #678747), but this isn't so major change. IMHO the tabs should point to some pages, not just actions as Drop/Empty tabs currently do. I would like them much more as link or button (red button would look great ;-)).
ok. Just noticed now that the link is also visible on the "SQL" (tbl_properties.php3) tab: maybe also not the best place (has nothing to do with 'sql' itself).
Funny thing, I never noticed it there. :)
Neither did I, it is probably there to ease finding it....how about putting that link on bottom of each tbl_* page and don't add any tab for it ;-))). -- Regards Michal Cihar nijel at users dot sourceforge dot net http://cihar.liten.cz
Michal Cihar wrote:
HI
On Sunday 02 February 2003 22:53, garvin_mailings@supergarv.de wrote:
How about the term 'External'?
It first made me think about my HP48 and the sysrpl programmation based on "Externals" :) Would be an option, but "Import" and "Export" are probably much clearer, especially for non programmers.
True...How about "Files" then? :-)
That sounds better...
From the numerous messages we get on the forums, users don't want to think, they just want to see Import and Export! They see Dump, they don't understand. Marc
On Sun, Feb 02, 2003 at 06:18:12PM +0100, Michal Cihar wrote:
It's a detail, but do you think it's the right place for this link? :) It has nothing to do with the table structure...
Indeed, I got few questions how to import text files, because people didn't find it there.
exactely, got the same feedback, and even got the problem myself once :)
Other possibilty: move the link to the "Insert" page (would also be quite logical), or to the Operations page. What do you think? :)
It is not on separate tab, because we have enough tabs now ;-). Export/Import name is long, it would b almost same. Even current layout won't fit on 800 pixels..... If you will find one (short) word for Export/Import tab....
E/I, I/O :) "File Operations", but that is not shorter... :)
Better would be to move Empty and Drop links (they are not used too much, and I see no reason why to have separate tabs for them) on Operations tab and add Import tab. How about that?
right, I never used the drop/empty tabs yet: usually doing theses operations from the db_details_structure.php3 page, but maybe some people won't like that... But I do think there are too many tabs: what about merging "Operations" and "Options" too ? Résumé of the suggestions: - add an "Import" tab - remove the Empty/Drop tabs - merge Operations/Options -> "Operations" Ok for everybody ? I guess not... let's see... :) Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland qmail projects: http://omail.omnis.ch - http://webmail.omnis.ch
Olivier M. wrote:
On Sun, Feb 02, 2003 at 06:18:12PM +0100, Michal Cihar wrote:
It's a detail, but do you think it's the right place for this link? :) It has nothing to do with the table structure...
Indeed, I got few questions how to import text files, because people didn't find it there.
exactely, got the same feedback, and even got the problem myself once :)
Other possibilty: move the link to the "Insert" page (would also be quite logical), or to the Operations page. What do you think? :)
It is not on separate tab, because we have enough tabs now ;-). Export/Import name is long, it would b almost same. Even current layout won't fit on 800 pixels..... If you will find one (short) word for Export/Import tab....
E/I, I/O :) "File Operations", but that is not shorter... :)
Better would be to move Empty and Drop links (they are not used too much, and I see no reason why to have separate tabs for them) on Operations tab and add Import tab. How about that?
right, I never used the drop/empty tabs yet: usually doing theses operations from the db_details_structure.php3 page, but maybe some people won't like that...
But I do think there are too many tabs: what about merging "Operations" and "Options" too ?
Résumé of the suggestions: - add an "Import" tab
I would prefer "Insert" -> "Insert/Import", and move the link "Insert data..." on the Insert/Import page.
- remove the Empty/Drop tabs
Not sure about this.
- merge Operations/Options -> "Operations"
Ok.
Ok for everybody ? I guess not... let's see... :) Olivier
See features request 618255. Marc Olivier M. wrote:
Hello,
At the end of the tbl_properties_structure.php3 page there is, when allowed, the * Insert data from a textfile into table link.
It's a detail, but do you think it's the right place for this link? :) It has nothing to do with the table structure...
Where could we move it ? "Export" has it's own tab, so "Import" would ne nice, and display the whole form generated by ldi_table.php3. But there are already too many tabs: maybe Export could be renamed to "Export/Import"?
Other possibilty: move the link to the "Insert" page (would also be quite logical), or to the Operations page.
What do you think? :) regards, Olivier
Hi Oliver & list, -----Original Message----- From: phpmyadmin-devel-admin@lists.sourceforge.net
At the end of the tbl_properties_structure.php3 page there is, when allowed, the * Insert data from a textfile into table link.
It's a detail, but do you think it's the right place for this link? :) It has nothing to do with the table structure...
I think someone put it there because he didn't know where else he should put it. :o) Imho the whole import stuff is not centralized enough: We have a link to the textfile import, the docSQL import link is somewhere else and the upload field for SQL files is on the "SQL" tab...
Where could we move it ? "Export" has it's own tab, so "Import" would ne nice, and display the whole form generated by ldi_table.php3. But there are already too many tabs: maybe Export could be renamed to "Export/Import"?
Other possibilty: move the link to the "Insert" page (would also be quite logical), or to the Operations page.
What do you think? :)
Well, some time ago, I suggested to move the query box to a JS window that may be opened via a link in the left frame. If we used this idea, we could replace the old "SQL" tabs (in the db view as well as in the table view) by an "Insert" tab. Here, we could put the whole upload and import stuff. I know this requires JS, but I'm sure we'll find a solution for this :-) Regards, Alexander M. Turek <alex@bugfixes.info> +-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+
Hi On Sunday 02 February 2003 22:16, Rabus wrote:
Well, some time ago, I suggested to move the query box to a JS window that may be opened via a link in the left frame. If we used this idea, we could replace the old "SQL" tabs (in the db view as well as in the table view) by an "Insert" tab. Here, we could put the whole upload and import stuff. I know this requires JS, but I'm sure we'll find a solution for this :-)
I don't like JS popups at all, they just make more opened windows and so cause larger mess on my desktops... And I don't se any need for one more window here. -- Regards Michal Cihar nijel at users dot sourceforge dot net http://cihar.liten.cz
Hi!
Well, some time ago, I suggested to move the query box to a JS window that may be opened via a link in the left frame. If we used this idea, we could replace the old "SQL" tabs (in the db view as well as in the table view) by an "Insert" tab. Here, we could put the whole upload and import stuff. I know this requires JS, but I'm sure we'll find a solution for this :-)
Even though something inside myself screams against using a popupwindow and JS-only features, I get to like the idea. But I think this is technically hard to get to work. I think the feature would make only sense if the window could hover the whole time on screen and will get updated with every query, leaving a query-history (which I personally would love to have implemented). And there's the problem, without a session management you can't get the variable transmission really to work. Because of the size of a query, you have to do it via POST. You can't redirect form-data from within a popup to the parent page. So you have to submit to the popup, which then remotely controls a hidden form in the left frame (by using opener.form.hiddenarea.value = $_POST['sql']) and then remotely submitting that form inside the left frame. We could, however make this popup window configable and throw the SQL box in, if the popup is disabled. We would then have to have a new place for it, if the SQL-button get's canceld, or display that label only for JS-disabled browsers. Well...after I'm done with mime-stuff and if this is a way to go for others I could volunteer to implement the above mentioned approach. For SQL-history's sake! :) BTW, as I'm not into the project in general, what are/were your reasons against sessions, if any? Regards, Garvin.
On Sunday 02 February 2003 23:13, garvin_mailings@supergarv.de wrote:
BTW, as I'm not into the project in general, what are/were your reasons against sessions, if any?
Probably because it is a lot of work to make run it in every possible setup... In PHP 4 are session quite easy, but in PHP 3 you have to write them by own or use another library that implements it and you need some place to store the session data. You need to make it work also without cookies as some users have them disabled... and probably more problems ;-) -- Regards Michal Cihar nijel at users dot sourceforge dot net http://cihar.liten.cz
Hi!
Probably because it is a lot of work to make run it in every possible setup... In PHP 4 are session quite easy, but in PHP 3 you have to write them by own or use another library that implements it and you need some place to store the session data. You need to make it work also without cookies as some users have them disabled... and probably more problems ;-)
Which means, current and future phpMyAdmin-release will always be targeted at a PHP3 audience as well? It's not that I think sessions are neccessary for phpMyAdmin, but at some point I think new features have to overwhelm the effort to stay backwards-compatible, also because PHP3 get's deprecated nowadays (simply because of security issues. I wouldn't want older exploitable php-versions running on my server). And even then, PHP3-users surely upgrade their phpMyAdmin releases as often as they upgrade their PHP3... ;-) Just a general thought, but I think currently there are other tasks to fulfill than implementing sessions. Regards, Garvin.
Hi On Sunday 02 February 2003 23:45, garvin_mailings@supergarv.de wrote:
Which means, current and future phpMyAdmin-release will always be targeted at a PHP3 audience as well?
Yes, as long as it is possible...
It's not that I think sessions are neccessary for phpMyAdmin, but at some point I think new features have to overwhelm the effort to stay backwards-compatible, also because PHP3 get's deprecated nowadays (simply because of security issues. I wouldn't want older exploitable php-versions running on my server). And even then, PHP3-users surely upgrade their phpMyAdmin releases as often as they upgrade their PHP3... ;-)
There are situations where you can't upgrade php (you have only user acount) but you can (and want) upgrade phpMyAdmin. I still have acoount on one such machine, but I've currently almost pushed admin to upgrade PHP ;-). -- Regards Michal Cihar nijel at users dot sourceforge dot net http://cihar.liten.cz
-----Original Message----- From: garvin_mailings@supergarv.de
Well, some time ago, I suggested to move the query box to a JS window that may be opened via a link in the left frame. If we used this idea, we could replace the old "SQL" tabs (in the db view as well as in the table view) by an "Insert" tab. Here, we could put the whole upload and import stuff. I know this requires JS, but I'm sure we'll find a solution for this :-)
Even though something inside myself screams against using a popupwindow and JS-only features, I get to like the idea.
This won't be a JS-only feature. For non-JS users we could still offer an alternative SQL page.
But I think this is technically hard to get to work. I think the feature would make only sense if the window could hover the whole time on screen and will get updated with every query, leaving a query-history (which I personally would love to have implemented). And there's the problem, without a session management you can't get the variable transmission really to work. Because of the size of a query, you have to do it via POST. You can't redirect form-data from within a popup to the parent page. So you have to submit to the popup, which then remotely controls a hidden form in the left frame (by using opener.form.hiddenarea.value = $_POST['sql']) and then remotely submitting that form inside the left frame.
Well, lets leave the query history for now, that's making the whole thing to complicated :o) My idea was to make the query box available from every section of phpMyAdmin without having to leave the current page, e.g. if you view a query result and want to send a new query for which you need a couple of values from this result page. It should be technically possible: The user clicks on a link in the left frame that opens and focuses the popup window with the SQL query box. He enters his query and submits it directly to the main frame of phpMyAdmin instead of the popup window itself. Then, the result page would close the window automatically. -----Original Message----- From: Michal Cihar % % I don't like JS popups at all, they just make more opened % windows and so cause larger mess on my desktops... And I % don't se any need for one more window here. I'd normally agree with you, Michal, but I don't see your point here. This popup doesn't hurt anyone: You open it, type your query in, press submit and the windows closes itself... btw, you should give Opera a try, if you want to manage your browser windows in a better way :-)
We could, however make this popup window configable and throw the SQL box in, if the popup is disabled. We would then have to have a new place for it, if the SQL-button get's canceld, or display that label only for JS-disabled browsers.
imho, the link should be displayed for both: - For JS-users, it opens the popup and - for non-JS-users, it opens the query box in the main frame.
Well...after I'm done with mime-stuff and if this is a way to go for others I could volunteer to implement the above mentioned approach. For SQL-history's sake! :)
We won't stop you :o)
BTW, as I'm not into the project in general, what are/were your reasons against sessions, if any?
First of all, the PHP3 compatibility. We try to keep the code PHP3 compatible as far as possible so we cannot take session support as a requirement of phpMyAdmin. But imho it'll be great to use sessions. This should lower down the traffic a lot. I even thought about a session-equivalent to the cookie authentification mode. The problem always was to pass the session ID between the scripts if it cannot be stored in a cookie and the transparent SID is disabled. But this should be much easier now because of Michal's great URL query generator code. So far, Alexander M. Turek <alex@bugfixes.info> +-----------------------------+ | The phpMyAdmin Project | | http://www.phpmyadmin.net | | rabus@users.sourceforge.net | +-----------------------------+ | [bugfixes.info] | | http://www.bugfixes.info | | rabus@bugfixes.info | +-----------------------------+
On Mon, Feb 03, 2003 at 12:02:53AM +0100, Rabus wrote:
BTW, as I'm not into the project in general, what are/were your reasons against sessions, if any?
First of all, the PHP3 compatibility. We try to keep the code PHP3 compatible as far as possible so we cannot take session support as a requirement of phpMyAdmin. But imho it'll be great to use sessions. This should lower down the traffic a lot. I even thought about a session-equivalent to the cookie authentification mode.
It would be interesting to see how many people are still using PHP3... Found only stats for php alone (for example: http://www.securityspace.com/s_survey/data/man.200212/apachemods.html ), nothing comparing php3 and php4. http://sourceforge.net/project/showfiles.php?group_id=23067 shows that there are about 10% people downloading the archive with php3 file endings, but does it really mean something? I also usualy get the "php3" version, just to be able to update easily with a cvs update... Should we drop php3 support ? PHP4 is already 2 years old now :) regards, Olivier -- _________________________________________________________________ Olivier Mueller - om@8304.ch - PGPkeyID: 0E84D2EA - Switzerland
participants (6)
-
garvin_mailings＠supergarv.de -
Marc Delisle -
Marc Delisle
-
Michal Cihar -
Olivier M. -
Rabus