Re: [Phpmyadmin-devel] AJAXify phpMyAdmin Interface - GSOC 2011 - Table->Operations -> table options
Hi Marc,
- For "*Table options*" if I add the ajax behavior to submit the
form without reloading the page I may need to replace all the table parameters which are currently embedded with the "*href*" attributes in the whole page. As an example it I change the table name from "actor" to "actor1" using "*Table options*" I may need to change the "*href*" of all four links in "*Table maintenance*" and "*Delete data or table*" to actor1 by using ajax. Is it okay to do that.Yes.
I tried to work with this feature. I faces following problems with that.
1. Currently the logic is handled under the "*if (isset($_REQUEST['submitoptions']))*" section in tbl_operations.php file. If I apply the ajax submission which submits the form without reloading the page, to this form I need to get the whole form as the response for the submission and replace it with the current form, because we don't know what values get changed. For getting the form as a response I need to get the html content of the updated "*Table operations*", so it will not be a small json response like in other cases (ex: in "Alter table oder by" ajax submission it retrieves a small json response with the message). So it will be costly for the operation. 2. Then if we used this form to rename the table (ex: "actor" to "actor1") we need to change each an every place where we use the actor name such as links in Top menu container, hidden fields in all the form within this page which carries the table name (ex: <input type="hidden" name="table" value="actor">. If not we have to replace whole page with the update page using ajax, but this is costly.
So I think it is better to leave this option with the normal form submission without converting it to ajax submission. What is your idea on that.
Regards, Thilanka.
Thilanka Kaushalya a écrit :
Hi Marc,
> 2. For "*Table options*" if I add the ajax behavior to submit the > form without reloading the page I may need to replace all the > table parameters which are currently embedded with the "*href*" > attributes in the whole page. As an example it I change the table > name from "actor" to "actor1" using "*Table options*" I may need > to change the "*href*" of all four links in "*Table maintenance*" > and "*Delete data or table*" to actor1 by using ajax. Is it okay > to do that. Yes.I tried to work with this feature. I faces following problems with that.
- Currently the logic is handled under the "*if (isset($_REQUEST['submitoptions']))*" section in tbl_operations.php file. If I apply the ajax submission which submits the form without reloading the page, to this form I need to get the whole form as the response for the submission and replace it with the current form, because we don't know what values get changed. For getting the form as a response I need to get the html content of the updated "*Table operations*", so it will not be a small json response like in other cases (ex: in "Alter table oder by" ajax submission it retrieves a small json response with the message). So it will be costly for the operation.
- Then if we used this form to rename the table (ex: "actor" to "actor1") we need to change each an every place where we use the actor name such as links in Top menu container, hidden fields in all the form within this page which carries the table name (ex: <input type="hidden" name="table" value="actor">. If not we have to replace whole page with the update page using ajax, but this is costly.
So I think it is better to leave this option with the normal form submission without converting it to ajax submission. What is your idea on that.
Ok for me. What do you plan to convert to Ajax instead of this?
Hi Marc,
On Mon, Aug 8, 2011 at 5:27 PM, Marc Delisle marc@infomarc.info wrote:
Thilanka Kaushalya a écrit :
Hi Marc,
> 2. For "*Table options*" if I add the ajax behavior to submitthe
> form without reloading the page I may need to replace allthe
> table parameters which are currently embedded with the"*href*"
> attributes in the whole page. As an example it I change the table > name from "actor" to "actor1" using "*Table options*" I may need > to change the "*href*" of all four links in "*Table maintenance*" > and "*Delete data or table*" to actor1 by using ajax. Is it okay > to do that. Yes.I tried to work with this feature. I faces following problems with that.
- Currently the logic is handled under the "*if (isset($_REQUEST['submitoptions']))*" section in tbl_operations.php file. If I apply the ajax submission which submits the form without reloading the page, to this form I need to get the whole form as the response for the submission and replace it with the current form, because we don't know what values get changed. For getting the form as a response I need to get the html content of the updated "*Table operations*", so it will not be a small json response like in other cases (ex: in "Alter table oder by" ajax submission it retrieves a small json response with the message). So it will be costly for the operation.
- Then if we used this form to rename the table (ex: "actor" to "actor1") we need to change each an every place where we use the actor name such as links in Top menu container, hidden fields in all the form within this page which carries the table name (ex: <input type="hidden" name="table" value="actor">. If not we have to replace whole page with the update page using ajax, but this is costly.
So I think it is better to leave this option with the normal form submission without converting it to ajax submission. What is your idea on that.
Ok for me. What do you plan to convert to Ajax instead of this?
I can work with the ajaxifying Table -> Insert -> insert row. Currently after each insertion, the page reloads to the "SQL" tab. Is it necessary. We can modify it to insert and wait within the insert tab without redirecting to the "SQL" tab. Please let me know your ideas on this.
If you find any other important feature to work other than this, please let me know.
Regards, Thilanka.
Le 2011-08-09 21:23, Thilanka Kaushalya a écrit :
Hi Marc,
On Mon, Aug 8, 2011 at 5:27 PM, Marc Delisle marc@infomarc.info wrote:
Thilanka Kaushalya a écrit :
Hi Marc,
> 2. For "*Table options*" if I add the ajax behavior to submitthe
> form without reloading the page I may need to replace allthe
> table parameters which are currently embedded with the"*href*"
> attributes in the whole page. As an example it I change the table > name from "actor" to "actor1" using "*Table options*" I may need > to change the "*href*" of all four links in "*Table maintenance*" > and "*Delete data or table*" to actor1 by using ajax. Is it okay > to do that. Yes.I tried to work with this feature. I faces following problems with that.
- Currently the logic is handled under the "*if (isset($_REQUEST['submitoptions']))*" section in tbl_operations.php file. If I apply the ajax submission which submits the form without reloading the page, to this form I need to get the whole form as the response for the submission and replace it with the current form, because we don't know what values get changed. For getting the form as a response I need to get the html content of the updated "*Table operations*", so it will not be a small json response like in other cases (ex: in "Alter table oder by" ajax submission it retrieves a small json response with the message). So it will be costly for the operation.
- Then if we used this form to rename the table (ex: "actor" to "actor1") we need to change each an every place where we use the actor name such as links in Top menu container, hidden fields in all the form within this page which carries the table name (ex: <input type="hidden" name="table" value="actor">. If not we have to replace whole page with the update page using ajax, but this is costly.
So I think it is better to leave this option with the normal form submission without converting it to ajax submission. What is your idea on that.
Ok for me. What do you plan to convert to Ajax instead of this?
I can work with the ajaxifying Table -> Insert -> insert row. Currently after each insertion, the page reloads to the "SQL" tab. Is it necessary. We can modify it to insert and wait within the insert tab without redirecting to the "SQL" tab. Please let me know your ideas on this.
I'm not sure we should ajaxify this right now. The reason is that if this means that the insert panel will be reduced (like what is done for create table), it could diminish usability.
We already have to deal with the problems caused by the reduced Create table panel, so let's not add a reduced panel for Insert.
If you find any other important feature to work other than this, please let me know.
Something useful would be to convert older code to jQuery, like libraries/js/querywindow.js.
Regards, Thilanka.
uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi Marc,
I'm not sure we should ajaxify this right now. The reason is that if this means that the insert panel will be reduced (like what is done for create table), it could diminish usability.
We already have to deal with the problems caused by the reduced Create table panel, so let's not add a reduced panel for Insert.
If you find any other important feature to work other than this, please
let
me know.
Something useful would be to convert older code to jQuery, like libraries/js/querywindow.js.
I started rewrite the four functions in querywindow.js file. But I have the issue with that.
1. I rewrote the "*PMA_querywindowCommit()*" and "* PMA_querywindowSetFocus()*" functions and since those functions are triggered when clicking on "*SQL*" tab I can check the accuracy of the modifications. But I cannot find a scenario where I can check "* PMA_queryAutoCommit()*" and "*PMA_querywindowResize()*" functions. Please can you explain me a scenario where these two functions are use.
Thank you.
Regards, Thilanka.
Thilanka Kaushalya a écrit :
Hi Marc,
I'm not sure we should ajaxify this right now. The reason is that if this means that the insert panel will be reduced (like what is done for create table), it could diminish usability. We already have to deal with the problems caused by the reduced Create table panel, so let's not add a reduced panel for Insert. > > If you find any other important feature to work other than this, please let > me know. Something useful would be to convert older code to jQuery, like libraries/js/querywindow.js.I started rewrite the four functions in querywindow.js file. But I have the issue with that.
- I rewrote the "*PMA_querywindowCommit()*" and "*PMA_querywindowSetFocus()*" functions and since those functions are triggered when clicking on "*SQL*" tab I can check the accuracy of the modifications. But I cannot find a scenario where I can check "*PMA_queryAutoCommit()*" and "*PMA_querywindowResize()*" functions. Please can you explain me a scenario where these two functions are use.
Thilanka, If I understand the code in querywindow.php correctly: in the query window, when you display the SQL history and click on a query to execute it, PMA_queryAutoCommit() is triggered. However in my tests I could not discover how to execute this code, so if you don't find a working scenario, please do not rewrite this one.
For PMA_querywindowResize(), this code is triggered when the query window is displayed or resized.
Hi Marc,
Thilanka, If I understand the code in querywindow.php correctly: in the query window, when you display the SQL history and click on a query to execute it, PMA_queryAutoCommit() is triggered. However in my tests I could not discover how to execute this code, so if you don't find a working scenario, please do not rewrite this one.
Since I could not find any scenario which trigger the PMA_queryAutoCommit() function I didn't convert it to jquery.
I modified other functions using jquery but basically used existing "* sizeToContent*" , "*resizeBy*" , "*resizeTo*" and "*focus*" functions which are in pure js to the logic. Is it okay or should I rewrote those functions in jquery.
I pushed the changes to the repo. Please check that. Thank you.
Regards, Thilanka.
-- Marc Delisle http://infomarc.info
uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-08-20 06:36, Thilanka Kaushalya a écrit :
Hi Marc,
Thilanka, If I understand the code in querywindow.php correctly: in the query window, when you display the SQL history and click on a query to execute it, PMA_queryAutoCommit() is triggered. However in my tests I could not discover how to execute this code, so if you don't find a working scenario, please do not rewrite this one.
Since I could not find any scenario which trigger the PMA_queryAutoCommit() function I didn't convert it to jquery.
I modified other functions using jquery but basically used existing "* sizeToContent*" , "*resizeBy*" , "*resizeTo*" and "*focus*" functions which are in pure js to the logic. Is it okay or should I rewrote those functions in jquery.
It's fine.
I pushed the changes to the repo. Please check that. Thank you.
Merged to origin/master.
Regards, Thilanka.
-
Marc Delisle -
Thilanka Kaushalya