Hi,
with the redesign of left panel, I wonder if we still need the queryframe functionality and config variables. (I am not talking about the query window).
Or am I missing something?
Comments?
Marc
On 15.06.2004 11:41 -0400, Marc Delisle wrote:
with the redesign of left panel, I wonder if we still need the queryframe functionality and config variables. (I am not talking about the query window).
Or am I missing something?
It saves something from being reloaded when tables/db list get changed. But I'm not sure whether it is worth of it.
I'm for merging query frame with left.
Hi!
It saves something from being reloaded when tables/db list get changed. But I'm not sure whether it is worth of it.
I'm for merging query frame with left.
Merging the frames will destroy the query's window functionality to let it stay open and handle your click paths.
I'm -10 ;) for merging, and sorry for writing so short - have no time. :(
Regards, Garvin.
On 15.06.2004 18:34 +0200, Garvin Hicking wrote:
Merging the frames will destroy the query's window functionality to let it stay open and handle your click paths.
I'm -10 ;) for merging, and sorry for writing so short - have no time. :(
Could you please explain this a bit more later, when you have time?
Hi Michal!
Merging the frames will destroy the query's window functionality to let it stay open and handle your click paths.
I'm -10 ;) for merging, and sorry for writing so short - have no time. :(
Could you please explain this a bit more later, when you have time?
Okay, here I'll try:
The queryframe is one frame which will never get reloaded. Thus it's a perfect place to store persistant javascript variables. Storing them inside the left frame will make this not possible.
The persistant variables are used to store the last used DB and Table name, and used in this kind of situation: I open PMA, open the querywindow, type some queries. Then I switch the DB/Table inside my PMA, browse a bit, and then want to use a query on that DB/Table. Without queryframe, it would use the DB/Table when the window was opened.
It is not possible to rewrite this code in a way that those variables are inside the querywindow instead of the queryframe, because once the left frame is loaded, the target window cannot be accessed anymore, as the opener/parent changes.
For me, removing the queryframe would be to remove useful functionality. If we were to drop the whole frameset-concept, that would be acceptable. But I honestly see no reason to remove that useful frame, as long as we have frames. The current way, with an "info"-frame is quite good, IMHO, so I'd like to leave it that way.
Regards, Garvin.
On 16.06.2004 10:54 +0200, Garvin Hicking wrote:
The queryframe is one frame which will never get reloaded. Thus it's a perfect place to store persistant javascript variables. Storing them inside the left frame will make this not possible.
The persistant variables are used to store the last used DB and Table name, and used in this kind of situation: I open PMA, open the querywindow, type some queries. Then I switch the DB/Table inside my PMA, browse a bit, and then want to use a query on that DB/Table. Without queryframe, it would use the DB/Table when the window was opened.
It is not possible to rewrite this code in a way that those variables are inside the querywindow instead of the queryframe, because once the left frame is loaded, the target window cannot be accessed anymore, as the opener/parent changes.
For me, removing the queryframe would be to remove useful functionality. If we were to drop the whole frameset-concept, that would be acceptable. But I honestly see no reason to remove that useful frame, as long as we have frames. The current way, with an "info"-frame is quite good, IMHO, so I'd like to leave it that way.
I didn't look at the details, but why these variables can not be in top frame? It also isn't reloaded...
Hi Michal!
I didn't look at the details, but why these variables can not be in top frame? It also isn't reloaded...
Hm, you could be right; however the code needs some rewrite to reference the top frame in all occassions. And currently the variables are stored inside a form container; I think this isn't W3C-valid inside a top-frameset, so we need to adjust that to purely JS variables which update a left frameset form (from where the window is opened).
Regards, Garvin.
-
Garvin Hicking -
Marc Delisle -
Michal Čihař