partner[etc], > Currently, when the pan ends, an onEnd event is fired, which then > fires off the ajax. So what you're suggesting is that i queue the pan > onEnd events?
Nope, I think. Back to your "pan-pan-pan-pan-pan" situation, doing what you suggest would still fire 5 times (onEnd fires after each individual pan) .... correct? ....What Shawn actually suggested (and from your reply, sounds like you may not have understood) was to delay executing your ajax request until a setTimeout timer expires. If another pan event happens during the timeout period, you reset the timeout & start the timer over. So, that's not a queue. The beauty with the timer is you don't flood the server with useless requests. I've used the timeout trick for ajax requests triggered by hover events on table rows. Same situation as yours - it only makes sense to do the ajax request when the user takes a 200ms (or whatever you think is appropriate) break. If you appreciate good UI design, throw a "loading" indicator up immediately (during the timeout period) to indicate to the user that something is happening. If you are worried about your ajax response taking longer than 200ms or whatever you use for the timer delay, then you'll need the ajax request queue solution too of course, but judging from your discussion, the timeout method will take care of 99% of the problem & it's more direct fix for the problem as you described it. -Wick http://www.CarComplants.com On Jul 16, 9:47 pm, partner56290674 <[EMAIL PROTECTED]> wrote: > I suppose shawn we can just agree to disagree because your comments > about it's application specific, IMO, is completly misguided in this > topic. IMO, it's not application specific but a option for any > developer to use. I don't see it as something very specific, no more > than jquery having an @each syntax thingy. I read your comment as 'i > want to do this and i don't know how, so jQuery, can you do this for > me because i don't know how/can't be bothered'. Even the next reply is > doing some queuing, so i can't be THAT far removed. If it's in the > Core, then it's assumed it's an important wrapper to help developers > maximize the technology they are using. > > After all this, though ... this is my personal opinion of how i see > things against yours .. and neither of us are wrong or write .. it's > personal opinion. > > The topic asked if this functionality was in the core - and it's not. > I suppose you're 100% right in seeing if John Resig and the krew think > this is an important option which could see benefit from the > community... or just more debate. > > :)
