[Phpmyadmin-devel] Inline edit and UPDATE feedback

Sun Mar 20 15:12:52 CET 2011

On Sun, Mar 20, 2011 at 5:18 PM, Marc Delisle <marc at 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 at 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 at 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 at 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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20110320/e69f8f82/attachment.html>