> 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.
