[Phpmyadmin-devel] problem with the new index editor

[Rouslan Placella]

On 22/12/11 11:29, Marc Delisle wrote:
> Le 2011-12-19 16:13, Rouslan Placella a écrit :
>> On 19/12/11 20:48, Marc Delisle wrote:
>>> Marc Delisle a écrit :
>>>> Rouslan Placella a écrit :
>>>>> On 19/12/11 20:29, Marc Delisle wrote:
>>>>>> Rouslan Placella a écrit :
>>>>>>> On 19/12/11 08:37, Piotr Przybylski wrote:
>>>>>>>> 2011/12/19 Rouslan Placella<rouslan at placella.com>:
>>>>>>>>> On 18/12/11 22:35, Piotr Przybylski wrote:
>>>>>>>>>> 2011/12/18 Rouslan Placella<rouslan at placella.com>:
>>>>>>>>>>> On 18/12/11 13:52, Marc Delisle wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Try this on sakila.actor:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. edit the PRIMARY index and add first_name to it
>>>>>>>>>>>>
>>>>>>>>>>>> 2. edit it again and remove first_name
>>>>>>>>>>>>
>>>>>>>>>>>> 3. edit it again: first_name is shown as being part of the index
>>>>>>>>>>>>
>>>>>>>>>>> Cached pages are being served. I noticed that as well, and the issue
>>>>>>>>>>> seems to be quite old. I'm guessing that PMA_ajaxResponce, which sends a
>>>>>>>>>>> no-cache header, is not being used to handle these requests.
>>>>>>>>>>>
>>>>>>>>>> How about solving caching issue globally with jQuery.ajaxSetup() [1]:
>>>>>>>>>>
>>>>>>>>>> $.ajaxSetup({cache: false});
>>>>>>>>>>
>>>>>>>>>> Cacheing issues pop up once in a while, this should solve them once
>>>>>>>>>> and for all.
>>>>>>>>>>
>>>>>>>>>> [1] http://api.jquery.com/jQuery.ajaxSetup/
>>>>>>>>>>
>>>>>>>>> Last time I tried, this didn't work for me. Not sure why, but the random
>>>>>>>>> variable that jQuery is supposed to append to the HTTP request was not
>>>>>>>>> coming up...
>>>>>>>> Ok, it seems it's not added for GET and HEAD requests... maybe we
>>>>>>>> could use jQuery.ajaxPrefilter to do add it to our urls. At least it
>>>>>>>> will still be a global solution.
>>>>>>>>
>>>>>>> OK, ajaxPrefilter it is then. I've added it for all AJAX requests, not
>>>>>>> just GET, since we were using ajaxSetup({cache:false}) in a few places
>>>>>>> for POST requests anyway. So this issue and anything else related to
>>>>>>> cached ajax requests should be solved now.
>>>>>>>
>>>>>>> Commit 0d7b3a5877dc71a0e43759a4bbba6f24ab1f0292
>>>>>> Hmmm, Firebug now shows thousands of errors, is it the same for you?
>>>>> No, I get no firebug errors. What are they? Are they gone if you go back
>>>>> a few revisions in git?
>>>>
>>>> I still need to find how they started. I was trying my sakila.actor test
>>>> case.
>>>>
>>>>
>>>
>>> I get
>>> $(this).data("qtip") is undefined
>>>
>>> Not yet sure how to reproduce this.
>>
>> Oh, that sounds familiar. I had gotten recursive qTip errors on several
>> occasions, but because I could never reproduce them I never reported
>> them. In my experience they happen most often in IE.
>>
>> I wonder if that has anything to do with the following code in
>> PMA_ajaxShowMessage():
>>
>> ------->% -------
>>        if (self_closing) {
>>            $retval
>>            .delay(timeout)
>>            .fadeOut('medium', function() {
>>                if ($(this).is('.dismissable')) {
>>                    // Here we should destroy the qtip instance, but
>>                    // due to a bug in qtip's implementation we can
>>                    // only hide it without throwing JS errors.
>>                    $(this).qtip('hide');
>>                }
>>                // Remove the notification
>>                $(this).remove();
>>            });
>>        }
>> ------->% -------
>>
>> In commit d424a797d5dd9e25a3c4a0923d45efdcf9005981 Piotr added the
>> $(this).remove() line because it interfered with the "full screen create
>> dialog table dialog" feature. But I wonder if that breaks qTip because
>> we are removing an element that qTip had registered internally.
>>
>> That said, I think that qTip sucks and, considering that qTip is taking
>> up 85 kB of code, I'm sure that we could get a smaller and more stable
>> tooltip plugin that suits our modest needs instead of it. Also qTip is
>> at an rc3 version and support for it has been dropped. This makes me
>> wonder why... Bad underlying architecture?
>
> They refer to qTip2 [0] that had activity 4 days ago.
>
> But we can look for something else. Were you thinking of switching
> before the phpMyAdmin 3.5.0 release?
>
> [0] https://github.com/craga89/qtip2

Yes, I was thinking of switching before 3.5.0. Michal's idea of 
upgrading to jQueryUI 1.9 sounds quite good, but I wouldn't be a big fan 
of including development versions into the code base. I'll have a look 
at what else is out there.

Rouslan