[Phpmyadmin-devel] problem with the new index editor

[Rouslan Placella]

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?

Thoughts?

Bye,
Rouslan