Hi, by default, the ShowSQL directive is true, which makes the generated SQL appear on top for almost every action. This fulfills many needs: - people teaching SQL - user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info wrote:
Hi, by default, the ShowSQL directive is true, which makes the generated SQL appear on top for almost every action. This fulfills many needs:
- people teaching SQL
- user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
-- Marc Delisle http://infomarc.info
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi,
We can add a field for the last inline_edit query run by the user, and display it using a show/hide button. This field can be added just beneath the "generatedSQL" which is always displayed.
-- Regards
Rohit Sharma CSE IIIT-Hyderabad http://iiit.net
Le 2011-03-19 16:21, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info wrote:
Hi, by default, the ShowSQL directive is true, which makes the generated SQL appear on top for almost every action. This fulfills many needs:
- people teaching SQL
- user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
Hi,
We can add a field for the last inline_edit query run by the user, and display it using a show/hide button. This field can be added just beneath the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 16:21, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info
wrote:
Hi, by default, the ShowSQL directive is true, which makes the generated SQL appear on top for almost every action. This fulfills many needs:
- people teaching SQL
- user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
Hi,
We can add a field for the last inline_edit query run by the user, and display it using a show/hide button. This field can be added just beneath the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
-- Marc Delisle http://infomarc.info
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi,
In case of Edit, the query tends to be small, "select * from table_name; " (talking generally, although the query can be much longer) , and on the other hand inline-edit queries are update queries which can be quite long for tables with more columns, hence it would take away some valuable space from the displayed table.
-- Regards
Rohit Sharma CSE IIIT-Hyderabad http://iiit.net/
Le 2011-03-19 16:42, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 16:21, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info
wrote:
Hi, by default, the ShowSQL directive is true, which makes the generated SQL appear on top for almost every action. This fulfills many needs:
- people teaching SQL
- user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
Hi,
We can add a field for the last inline_edit query run by the user, and display it using a show/hide button. This field can be added just beneath the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
Hi,
In case of Edit, the query tends to be small, "select * from table_name; " (talking generally, although the query can be much longer) , and on the other hand inline-edit queries are update queries which can be quite long for tables with more columns, hence it would take away some valuable space from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some row and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 16:42, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:21, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info
wrote:
Hi, by default, the ShowSQL directive is true, which makes the generated
SQL
appear on top for almost every action. This fulfills many needs:
- people teaching SQL
- user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
Hi,
We can add a field for the last inline_edit query run by the user, and display it using a show/hide button. This field can be added just
beneath
the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
Hi,
In case of Edit, the query tends to be small, "select * from table_name;
"
(talking generally, although the query can be much longer) , and on the other hand inline-edit queries are update queries which can be quite long for tables with more columns, hence it would take away some valuable
space
from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some row and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
-- Marc Delisle http://infomarc.info
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is being sent using Ajax, and the frame won't move after a query execution, so where do your propose to display the inline_edit query that was last run, so that the user gets notified.
-- Regards
Rohit Sharma CSE IIIT-Hyderabad http://iiit.net/
Le 2011-03-19 17:03, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 16:42, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:21, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info
wrote:
Hi, by default, the ShowSQL directive is true, which makes the generated
SQL
appear on top for almost every action. This fulfills many needs:
- people teaching SQL
- user who wants to verify what phpMyAdmin did in the backend
However with Inline edit, we no longer see this generated SQL and I'm wondering if something should be done about this.
Hi,
We can add a field for the last inline_edit query run by the user, and display it using a show/hide button. This field can be added just
beneath
the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
Hi,
In case of Edit, the query tends to be small, "select * from table_name;
"
(talking generally, although the query can be much longer) , and on the other hand inline-edit queries are update queries which can be quite long for tables with more columns, hence it would take away some valuable
space
from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some row and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is being sent using Ajax, and the frame won't move after a query execution, so where do your propose to display the inline_edit query that was last run, so that the user gets notified.
At the same place where it's displayed when using the non-Ajax Edit (but obviously not with the same mechanism).
But my initial question was not about implementation, it was about whether we should display UPDATE feedback at all for Inline edit.
On Sun, Mar 20, 2011 at 2:36 AM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 17:03, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:42, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:21, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info
wrote:
> Hi, > by default, the ShowSQL directive is true, which makes the generated
SQL
> appear on top for almost every action. This fulfills many needs: > - people teaching SQL > - user who wants to verify what phpMyAdmin did in the backend > > However with Inline edit, we no longer see this generated SQL and
I'm
> wondering if something should be done about this.
Hi,
We can add a field for the last inline_edit query run by the user,
and
display it using a show/hide button. This field can be added just
beneath
the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
Hi,
In case of Edit, the query tends to be small, "select * from
table_name;
"
(talking generally, although the query can be much longer) , and on the other hand inline-edit queries are update queries which can be quite
long
for tables with more columns, hence it would take away some valuable
space
from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some row and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is
being
sent using Ajax, and the frame won't move after a query execution, so
where
do your propose to display the inline_edit query that was last run, so
that
the user gets notified.
At the same place where it's displayed when using the non-Ajax Edit (but obviously not with the same mechanism).
But my initial question was not about implementation, it was about whether we should display UPDATE feedback at all for Inline edit.
-- Marc Delisle http://infomarc.info
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi,
After inline_edit, the user instantly gets notified of the change in the table since the position of the frame remains unchanged. Although it can be a good idea to display the query for users who wish to know what all happened in the backend and also, if my query is incorrect, I would like the error and the query to be displayed for a longer time (permanently) rather than for some short duration.
Also, if my inline_edit query is incorrect, a ajax window displays the error, but the "back" button on that window takes me all the way to "insert new record" appending the query in my URL, shouldn't it direct me to the same page as before ?
-- Regards
Rohit Sharma CSE IIIT-Hyderabad http://iiit.net
Le 2011-03-19 17:26, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:36 AM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 17:03, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:42, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:21, rohit sharma a écrit : > On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info wrote: > >> Hi, >> by default, the ShowSQL directive is true, which makes the generated
SQL
>> appear on top for almost every action. This fulfills many needs: >> - people teaching SQL >> - user who wants to verify what phpMyAdmin did in the backend >> >> However with Inline edit, we no longer see this generated SQL and
I'm
>> wondering if something should be done about this.
> > Hi, > > We can add a field for the last inline_edit query run by the user,
and
> display it using a show/hide button. This field can be added just
beneath
> the "generatedSQL" which is always displayed.
Hi, in the case of Edit, there is no Show/hide because the interface respects the $cfg['ShowSQL'] directive, so why should there be a Show/hide in the case of Inline Edit?
Hi,
In case of Edit, the query tends to be small, "select * from
table_name;
"
(talking generally, although the query can be much longer) , and on the other hand inline-edit queries are update queries which can be quite
long
for tables with more columns, hence it would take away some valuable
space
from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some row and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is
being
sent using Ajax, and the frame won't move after a query execution, so
where
do your propose to display the inline_edit query that was last run, so
that
the user gets notified.
At the same place where it's displayed when using the non-Ajax Edit (but obviously not with the same mechanism).
But my initial question was not about implementation, it was about whether we should display UPDATE feedback at all for Inline edit.
-- Marc Delisle http://infomarc.info
Hi,
After inline_edit, the user instantly gets notified of the change in the table since the position of the frame remains unchanged. Although it can be a good idea to display the query for users who wish to know what all happened in the backend and also, if my query is incorrect, I would like the error and the query to be displayed for a longer time (permanently) rather than for some short duration.
Thanks for your feedback. I believe that the UPDATE query should be displayed, if it works or not, at the same place than when using a traditional edit (if $cfg['ShowSQL'] is true).
Also, if my inline_edit query is incorrect, a ajax window displays the error, but the "back" button on that window takes me all the way to "insert new record" appending the query in my URL, shouldn't it direct me to the same page as before ?
Look on Google for "Ajax back button", you'll see that in general, back button with Ajax is problematic.
I think that we should concentrate on not generating a bad query for inline edit. Do you have a test case where inline edit generates wrong SQL?
On Sun, Mar 20, 2011 at 2:57 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 17:26, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:36 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 17:03, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:42, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info
wrote:
> Le 2011-03-19 16:21, rohit sharma a écrit : >> On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info > wrote: >> >>> Hi, >>> by default, the ShowSQL directive is true, which makes the
generated
SQL
>>> appear on top for almost every action. This fulfills many needs: >>> - people teaching SQL >>> - user who wants to verify what phpMyAdmin did in the backend >>> >>> However with Inline edit, we no longer see this generated SQL and
I'm
>>> wondering if something should be done about this. > >> >> Hi, >> >> We can add a field for the last inline_edit query run by the user,
and
>> display it using a show/hide button. This field can be added just
beneath
>> the "generatedSQL" which is always displayed. > > Hi, > in the case of Edit, there is no Show/hide because the interface > respects the $cfg['ShowSQL'] directive, so why should there be a > Show/hide in the case of Inline Edit?
Hi,
In case of Edit, the query tends to be small, "select * from
table_name;
"
(talking generally, although the query can be much longer) , and on
the
other hand inline-edit queries are update queries which can be quite
long
for tables with more columns, hence it would take away some valuable
space
from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some
row
and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is
being
sent using Ajax, and the frame won't move after a query execution, so
where
do your propose to display the inline_edit query that was last run, so
that
the user gets notified.
At the same place where it's displayed when using the non-Ajax Edit (but obviously not with the same mechanism).
But my initial question was not about implementation, it was about whether we should display UPDATE feedback at all for Inline edit.
-- Marc Delisle http://infomarc.info
Hi,
After inline_edit, the user instantly gets notified of the change in the table since the position of the frame remains unchanged. Although it can
be
a good idea to display the query for users who wish to know what all happened in the backend and also, if my query is incorrect, I would like
the
error and the query to be displayed for a longer time (permanently)
rather
than for some short duration.
Thanks for your feedback. I believe that the UPDATE query should be displayed, if it works or not, at the same place than when using a traditional edit (if $cfg['ShowSQL'] is true).
Also, if my inline_edit query is incorrect, a ajax window displays the error, but the "back" button on that window takes me all the way to
"insert
new record" appending the query in my URL, shouldn't it direct me to the same page as before ?
Look on Google for "Ajax back button", you'll see that in general, back button with Ajax is problematic.
Hi,
Then the "back" button makes no sense, because the user would like to stay on the same page and look at what went wrong, rather than going to any other page.
I think that we should concentrate on not generating a bad query for inline edit. Do you have a test case where inline edit generates wrong SQL?
I think when dealing with foreign keys one can come up with incorrect update statements. In that case, the error message being displayed using PMA_ajaxShowMessage() isn't helpful enough as it's just transient.
-- Regards
Rohit Sharma CSE IIIT-Hyderabad http://iiit.net/
--
Marc Delisle http://infomarc.info
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-03-20 07:26, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:57 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-19 17:26, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:36 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 17:03, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 16:42, rohit sharma a écrit : > On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info wrote: > >> Le 2011-03-19 16:21, rohit sharma a écrit : >>> On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle marc@infomarc.info >> wrote: >>> >>>> Hi, >>>> by default, the ShowSQL directive is true, which makes the
generated
SQL >>>> appear on top for almost every action. This fulfills many needs: >>>> - people teaching SQL >>>> - user who wants to verify what phpMyAdmin did in the backend >>>> >>>> However with Inline edit, we no longer see this generated SQL and
I'm
>>>> wondering if something should be done about this. >> >>> >>> Hi, >>> >>> We can add a field for the last inline_edit query run by the user,
and
>>> display it using a show/hide button. This field can be added just beneath >>> the "generatedSQL" which is always displayed. >> >> Hi, >> in the case of Edit, there is no Show/hide because the interface >> respects the $cfg['ShowSQL'] directive, so why should there be a >> Show/hide in the case of Inline Edit? > > Hi, > > In case of Edit, the query tends to be small, "select * from
table_name;
" > (talking generally, although the query can be much longer) , and on
the
> other hand inline-edit queries are update queries which can be quite
long
> for tables with more columns, hence it would take away some valuable space > from the displayed table.
I'm not sure I follow you. If you browse a table, click Edit on some
row
and make a change, you'll see the generated UPDATE statement, followed by a SELECT representing your current results set.
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is
being
sent using Ajax, and the frame won't move after a query execution, so
where
do your propose to display the inline_edit query that was last run, so
that
the user gets notified.
At the same place where it's displayed when using the non-Ajax Edit (but obviously not with the same mechanism).
But my initial question was not about implementation, it was about whether we should display UPDATE feedback at all for Inline edit.
-- Marc Delisle http://infomarc.info
Hi,
After inline_edit, the user instantly gets notified of the change in the table since the position of the frame remains unchanged. Although it can
be
a good idea to display the query for users who wish to know what all happened in the backend and also, if my query is incorrect, I would like
the
error and the query to be displayed for a longer time (permanently)
rather
than for some short duration.
Thanks for your feedback. I believe that the UPDATE query should be displayed, if it works or not, at the same place than when using a traditional edit (if $cfg['ShowSQL'] is true).
Also, if my inline_edit query is incorrect, a ajax window displays the error, but the "back" button on that window takes me all the way to
"insert
new record" appending the query in my URL, shouldn't it direct me to the same page as before ?
Look on Google for "Ajax back button", you'll see that in general, back button with Ajax is problematic.
Hi,
Then the "back" button makes no sense, because the user would like to stay on the same page and look at what went wrong, rather than going to any other page.
I don't understand your point. Why would the user click Back in this case? He is on the same page and should be able to fix the problem, or click Hide to quit inline editing.
I think that we should concentrate on not generating a bad query for inline edit. Do you have a test case where inline edit generates wrong SQL?
I think when dealing with foreign keys one can come up with incorrect update statements. In that case, the error message being displayed using PMA_ajaxShowMessage() isn't helpful enough as it's just transient.
Would it be better to show it during 10 seconds?
On Sun, Mar 20, 2011 at 5:18 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-20 07:26, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:57 PM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 17:26, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:36 AM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-19 17:03, rohit sharma a écrit :
On Sun, Mar 20, 2011 at 2:15 AM, Marc Delisle marc@infomarc.info
wrote:
> Le 2011-03-19 16:42, rohit sharma a écrit : >> On Sun, Mar 20, 2011 at 2:03 AM, Marc Delisle marc@infomarc.info > wrote: >> >>> Le 2011-03-19 16:21, rohit sharma a écrit : >>>> On Sun, Mar 20, 2011 at 1:45 AM, Marc Delisle <
marc@infomarc.info>
>>> wrote: >>>> >>>>> Hi, >>>>> by default, the ShowSQL directive is true, which makes the
generated
> SQL >>>>> appear on top for almost every action. This fulfills many needs: >>>>> - people teaching SQL >>>>> - user who wants to verify what phpMyAdmin did in the backend >>>>> >>>>> However with Inline edit, we no longer see this generated SQL
and
I'm
>>>>> wondering if something should be done about this. >>> >>>> >>>> Hi, >>>> >>>> We can add a field for the last inline_edit query run by the
user,
and
>>>> display it using a show/hide button. This field can be added just > beneath >>>> the "generatedSQL" which is always displayed. >>> >>> Hi, >>> in the case of Edit, there is no Show/hide because the interface >>> respects the $cfg['ShowSQL'] directive, so why should there be a >>> Show/hide in the case of Inline Edit? >> >> Hi, >> >> In case of Edit, the query tends to be small, "select * from
table_name;
> " >> (talking generally, although the query can be much longer) , and on
the
>> other hand inline-edit queries are update queries which can be
quite
long
>> for tables with more columns, hence it would take away some
valuable
> space >> from the displayed table. > > I'm not sure I follow you. If you browse a table, click Edit on some
row
> and make a change, you'll see the generated UPDATE statement,
followed
> by a SELECT representing your current results set.
Hi,
Thanks. I got the idea. But in the case of "inline_edit" the query is
being
sent using Ajax, and the frame won't move after a query execution,
so
where
do your propose to display the inline_edit query that was last run,
so
that
the user gets notified.
At the same place where it's displayed when using the non-Ajax Edit
(but
obviously not with the same mechanism).
But my initial question was not about implementation, it was about whether we should display UPDATE feedback at all for Inline edit.
-- Marc Delisle http://infomarc.info
Hi,
After inline_edit, the user instantly gets notified of the change in
the
table since the position of the frame remains unchanged. Although it
can
be
a good idea to display the query for users who wish to know what all happened in the backend and also, if my query is incorrect, I would
like
the
error and the query to be displayed for a longer time (permanently)
rather
than for some short duration.
Thanks for your feedback. I believe that the UPDATE query should be displayed, if it works or not, at the same place than when using a traditional edit (if $cfg['ShowSQL'] is true).
Also, if my inline_edit query is incorrect, a ajax window displays the error, but the "back" button on that window takes me all the way to
"insert
new record" appending the query in my URL, shouldn't it direct me to
the
same page as before ?
Look on Google for "Ajax back button", you'll see that in general, back button with Ajax is problematic.
Hi,
Then the "back" button makes no sense, because the user would like to
stay
on the same page and look at what went wrong, rather than going to any
other
page.
Hi,
I don't understand your point. Why would the user click Back in this case? He is on the same page and should be able to fix the problem, or click Hide to quit inline editing.
When an error appears in the "inline edit" query, the ajax message displayed is the error message, with a "back" button in the footer. I think the user would click on this button to go back to the page where the table is being displayed, rather he is being sent to some other page. Here is the error message: http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/err1.jpeg and after clicking on "back" the user is sent here: http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/err3.jpeg
I think that we should concentrate on not generating a bad query for inline edit. Do you have a test case where inline edit generates wrong
SQL?
I think when dealing with foreign keys one can come up with incorrect
update
statements. In that case, the error message being displayed using PMA_ajaxShowMessage() isn't helpful enough as it's just transient.
Would it be better to show it during 10 seconds?
In case of an error, it would be better to display the query permanently,
so to bring uniformity (either success or failure), the inline_edit query should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
-- Regards
Rohit Sharma CSE IIIT-Hyderabad http://iiit.net/
-- Marc Delisle http://infomarc.info
Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Le 2011-03-20 10:12, rohit sharma a écrit :
Thanks for your feedback. I believe that the UPDATE query should be displayed, if it works or not, at the same place than when using a traditional edit (if $cfg['ShowSQL'] is true).
When an error appears in the "inline edit" query, the ajax message displayed is the error message, with a "back" button in the footer. I think the user would click on this button to go back to the page where the table is being displayed, rather he is being sent to some other page.
OK I believed that you were talking about the browser's back button. You mean the "Back" link in the footer. I'll remove it, it's part of some HTML generated for the Edit page but should not appear as a result of Inline edit.
In case of an error, it would be better to display the query permanently,
so to bring uniformity (either success or failure), the inline_edit query should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
Thanks for the feedback, I'll work on this tomorrow.
Marc Delisle a écrit :
Le 2011-03-20 10:12, rohit sharma a écrit :
Thanks for your feedback. I believe that the UPDATE query should be displayed, if it works or not, at the same place than when using a traditional edit (if $cfg['ShowSQL'] is true).
When an error appears in the "inline edit" query, the ajax message displayed is the error message, with a "back" button in the footer. I think the user would click on this button to go back to the page where the table is being displayed, rather he is being sent to some other page.
OK I believed that you were talking about the browser's back button. You mean the "Back" link in the footer. I'll remove it, it's part of some HTML generated for the Edit page but should not appear as a result of Inline edit.
Back link now removed in the Inline edit situation.
In case of an error, it would be better to display the query permanently,
so to bring uniformity (either success or failure), the inline_edit query should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
Thanks for the feedback, I'll work on this tomorrow.
Le 2011-03-20 10:12, rohit sharma a écrit :
In case of an error, it would be better to display the query permanently,
so to bring uniformity (either success or failure), the inline_edit query should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
In case of success, query is now displayed; please try it.
Hi,
On Sat, Mar 26, 2011 at 5:32 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-20 10:12, rohit sharma a écrit :
In case of an error, it would be better to display the query
permanently,
so to bring uniformity (either success or failure), the inline_edit
query
should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
In case of success, query is now displayed; please try it.
Consider this scenario, I have a table with no index defined, and two columns, when I click "inline_edit" for any row, the row gets updated, and the message is shown properly. Now when I click "inline_edit" again for the same row, but changing the other column, the message shown is "0 Rows affected", although the row being displayed gets updated without any error. However a look at the query reveals that the query was in-fact incorrect, it was using the old value for the column that had been previously edited. Thus the row displayed is incorrect, because it never got updated. I am sending some screenshots to depict the same.
[0] http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_1... [ initial_setup ] [1] http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_2... [ updating row 2, col 2 ] [2] http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_3... [ updating row 2, col 1 ]
For [2] it outputs, "0 Rows updated", although it should update that row, because nothing is incorrect with the query. A look at sql.js reveals, that the column value in the new query does not get updated. Although while iterating over the elements "this_field_params[field_name] " contains the correct value, however the problem is the "where_clause" as it does not get updated. So the issue boils down to simply the " <input class=" where_clause"..> being incorrect. Which means as soon as we find a successful sql query, we must update the "where_clause". Should I file this as a bug ?
-- Regards
Rohit Sharma
Le 2011-03-26 09:21, rohit sharma a écrit :
Hi,
On Sat, Mar 26, 2011 at 5:32 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-20 10:12, rohit sharma a écrit :
In case of an error, it would be better to display the query
permanently,
so to bring uniformity (either success or failure), the inline_edit
query
should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
In case of success, query is now displayed; please try it.
Consider this scenario, I have a table with no index defined, and two columns, when I click "inline_edit" for any row, the row gets updated, and the message is shown properly. Now when I click "inline_edit" again for the same row, but changing the other column, the message shown is "0 Rows affected", although the row being displayed gets updated without any error. However a look at the query reveals that the query was in-fact incorrect, it was using the old value for the column that had been previously edited. Thus the row displayed is incorrect, because it never got updated. I am sending some screenshots to depict the same.
[0] http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_1... [ initial_setup ] [1] http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_2... [ updating row 2, col 2 ] [2] http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_3... [ updating row 2, col 1 ]
For [2] it outputs, "0 Rows updated", although it should update that row, because nothing is incorrect with the query. A look at sql.js reveals, that the column value in the new query does not get updated. Although while iterating over the elements "this_field_params[field_name] " contains the correct value, however the problem is the "where_clause" as it does not get updated. So the issue boils down to simply the " <input class=" where_clause"..> being incorrect. Which means as soon as we find a successful sql query, we must update the "where_clause". Should I file this as a bug ?
Please do.
On Sat, Mar 26, 2011 at 7:14 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-26 09:21, rohit sharma a écrit :
Hi,
On Sat, Mar 26, 2011 at 5:32 PM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-20 10:12, rohit sharma a écrit :
In case of an error, it would be better to display the query
permanently,
so to bring uniformity (either success or failure), the inline_edit
query
should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
In case of success, query is now displayed; please try it.
Consider this scenario, I have a table with no index defined, and two columns, when I click "inline_edit" for any row, the row gets updated,
and
the message is shown properly. Now when I click "inline_edit" again for
the
same row, but changing the other column, the message shown is "0 Rows affected", although the row being displayed gets updated without any
error.
However a look at the query reveals that the query was in-fact incorrect,
it
was using the old value for the column that had been previously edited. Thus the row displayed is incorrect, because it never got updated. I am sending some screenshots to depict the same.
[0]
http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_1...
[ initial_setup ] [1]
http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_2...
[ updating row 2, col 2 ] [2]
http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_3...
[ updating row 2, col 1 ]
For [2] it outputs, "0 Rows updated", although it should update that row, because nothing is incorrect with the query. A look at sql.js reveals,
that
the column value in the new query does not get updated. Although while iterating over the elements "this_field_params[field_name]
"
contains the correct value, however the problem is the "where_clause" as
it
does not get updated. So the issue boils down to simply the " <input
class="
where_clause"..> being incorrect. Which means as soon as we find a successful sql query, we must update the "where_clause".
Hi,
Should I file this as a bug ?
Please do.
Bug reported, updated diff uploaded, please test it.
https://sourceforge.net/tracker/?func=detail&aid=3249406&group_id=23...
-- Marc Delisle http://infomarc.info
Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Regards
Rohit Sharma
Le 2011-03-27 09:12, rohit sharma a écrit :
On Sat, Mar 26, 2011 at 7:14 PM, Marc Delisle marc@infomarc.info wrote:
Le 2011-03-26 09:21, rohit sharma a écrit :
Hi,
On Sat, Mar 26, 2011 at 5:32 PM, Marc Delisle marc@infomarc.info
wrote:
Le 2011-03-20 10:12, rohit sharma a écrit :
In case of an error, it would be better to display the query
permanently,
so to bring uniformity (either success or failure), the inline_edit
query
should be displayed permanently like in case of normal query with $cfg['ShowSQL'] set to true.
In case of success, query is now displayed; please try it.
Consider this scenario, I have a table with no index defined, and two columns, when I click "inline_edit" for any row, the row gets updated,
and
the message is shown properly. Now when I click "inline_edit" again for
the
same row, but changing the other column, the message shown is "0 Rows affected", although the row being displayed gets updated without any
error.
However a look at the query reveals that the query was in-fact incorrect,
it
was using the old value for the column that had been previously edited. Thus the row displayed is incorrect, because it never got updated. I am sending some screenshots to depict the same.
[0]
http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_1...
[ initial_setup ] [1]
http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_2...
[ updating row 2, col 2 ] [2]
http://web.iiit.ac.in/~rohit.sharmaug08/phpmyadmin/inline_edit/inline-edit_3...
[ updating row 2, col 1 ]
For [2] it outputs, "0 Rows updated", although it should update that row, because nothing is incorrect with the query. A look at sql.js reveals,
that
the column value in the new query does not get updated. Although while iterating over the elements "this_field_params[field_name]
"
contains the correct value, however the problem is the "where_clause" as
it
does not get updated. So the issue boils down to simply the " <input
class="
where_clause"..> being incorrect. Which means as soon as we find a successful sql query, we must update the "where_clause".
Hi,
Should I file this as a bug ?
Please do.
Bug reported, updated diff uploaded, please test it.
https://sourceforge.net/tracker/?func=detail&aid=3249406&group_id=23...
Moved to https://sourceforge.net/tracker/?func=detail&atid=377410&aid=3249406...
-
Marc Delisle -
rohit sharma