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
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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.
Rouslan
2011/12/18 Rouslan Placella rouslan@placella.com:
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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/
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@placella.com:
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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.
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...
2011/12/19 Rouslan Placella rouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@placella.com:
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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.
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.
Piotr Przybylski a écrit :
2011/12/19 Rouslan Placella rouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@placella.com:
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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.
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.
I confirm that $.ajaxPrefilter() as implemented by Rouslan's commit 0d7b3a5877dc71a0e43759a4bbba6f24ab1f0292 fixed my problematic case.
Thanks guys!
On 19/12/11 08:37, Piotr Przybylski wrote:
2011/12/19 Rouslan Placellarouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@placella.com:
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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.
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
Rouslan
Rouslan Placella a écrit :
On 19/12/11 08:37, Piotr Przybylski wrote:
2011/12/19 Rouslan Placellarouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@placella.com:
On 18/12/11 13:52, Marc Delisle wrote:
Hi,
Try this on sakila.actor:
edit the PRIMARY index and add first_name to it
edit it again and remove first_name
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.
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?
Marc Delisle a écrit :
Rouslan Placella a écrit :
On 19/12/11 08:37, Piotr Przybylski wrote:
2011/12/19 Rouslan Placellarouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@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.
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?
I'm not sure what I did to produce these, but they mentionned qtip data.
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 Placellarouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@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.
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?
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 Placellarouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote:
2011/12/18 Rouslan Placellarouslan@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.
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.
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 Placellarouslan@placella.com:
On 18/12/11 22:35, Piotr Przybylski wrote: > 2011/12/18 Rouslan Placellarouslan@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.
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 Placellarouslan@placella.com: > On 18/12/11 22:35, Piotr Przybylski wrote: >> 2011/12/18 Rouslan Placellarouslan@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
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 Placellarouslan@placella.com: >> On 18/12/11 22:35, Piotr Przybylski wrote: >>> 2011/12/18 Rouslan Placellarouslan@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
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 Placellarouslan@placella.com: >>> On 18/12/11 22:35, Piotr Przybylski wrote: >>>> 2011/12/18 Rouslan Placellarouslan@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?
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
Not following the discussion very much either but since we have really simple needs for tooltips maybe it's easier just to write our own? It's not much more than a styled <div> that needs to be positioned and shown/hidden. One of our gsoc students last summer had that already implemented such tooltip for the column reordering, iirc. Then we replaced that code with qTip for reasons I don't remember anymore. So it actually would be only a matter of restoring that old code from the repos history. Refactoring it into a jquery plugin would be useful though.
- Tyron
On Fri, Dec 23, 2011 at 2:15 PM, Rouslan Placella rouslan@placella.com wrote:
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 Placellarouslan@placella.com: >>>> On 18/12/11 22:35, Piotr Przybylski wrote: >>>>> 2011/12/18 Rouslan Placellarouslan@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?
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
Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On 23/12/11 16:35, Tyron Madlener wrote:
Not following the discussion very much either but since we have really simple needs for tooltips maybe it's easier just to write our own? It's not much more than a styled<div> that needs to be positioned and shown/hidden. One of our gsoc students last summer had that already implemented such tooltip for the column reordering, iirc. Then we replaced that code with qTip for reasons I don't remember anymore. So it actually would be only a matter of restoring that old code from the repos history. Refactoring it into a jquery plugin would be useful though.
Commit d5eca34f4f8bebc2dcef253fa6dad1aaaaf22546 ?
Aris, could you please have a look at this when you have some time? Thanks.
Rouslan
Hi
Dne Mon, 19 Dec 2011 21:13:15 +0000 Rouslan Placella rouslan@placella.com napsal(a):
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?
Maybe we could already switch to upcoming jQuery UI 1.9, which includes tootlip itself [1]? I've already done such switch for one project and it seems to work pretty good.
PS: Well I'm not following this discussion much, so this might be absolutely OT.
[1]:http://wiki.jqueryui.com/Tooltip
On 22/12/11 15:30, Michal Čihař wrote:
Hi
Dne Mon, 19 Dec 2011 21:13:15 +0000 Rouslan Placellarouslan@placella.com napsal(a):
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?
Maybe we could already switch to upcoming jQuery UI 1.9, which includes tootlip itself [1]? I've already done such switch for one project and it seems to work pretty good.
Any idea when they will deem their 1.9 branch stable?
Rouslan
Hi
Dne Fri, 23 Dec 2011 13:15:58 +0000 Rouslan Placella rouslan@placella.com napsal(a):
Any idea when they will deem their 1.9 branch stable?
No clue and I don't think there is clear plan for that: http://forum.jquery.com/topic/jquery-ui-1-9-release-date
On 23/12/11 13:20, Michal Čihař wrote:
Hi
Dne Fri, 23 Dec 2011 13:15:58 +0000 Rouslan Placellarouslan@placella.com napsal(a):
Any idea when they will deem their 1.9 branch stable?
No clue and I don't think there is clear plan for that: http://forum.jquery.com/topic/jquery-ui-1-9-release-date
From the roadmap, it looks like they have still quite a bit more to go. So, I might look for an alternative source for a tooltip widget.
Rouslan
Hi
Dne Fri, 23 Dec 2011 13:31:00 +0000 Rouslan Placella rouslan@placella.com napsal(a):
On 23/12/11 13:20, Michal Čihař wrote:
Hi
Dne Fri, 23 Dec 2011 13:15:58 +0000 Rouslan Placellarouslan@placella.com napsal(a):
Any idea when they will deem their 1.9 branch stable?
No clue and I don't think there is clear plan for that: http://forum.jquery.com/topic/jquery-ui-1-9-release-date
From the roadmap, it looks like they have still quite a bit more to go. So, I might look for an alternative source for a tooltip widget.
Indeed it might be better solution for now, however I did not see any issues with milestone I've used.
-
Marc Delisle -
Michal Čihař -
Piotr Przybylski -
Rouslan Placella -
Tyron Madlener