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?

--

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