Your situation is clearer now. I would think though that the solution
is a little simpler. Bear with me as I talk through this, but I haven't
had the joys of working with google maps like this (yet)...
So, user loads the page. Then user starts panning around. Rapidly.
Instead of trying to show EVERYTHING that every pan would result in,
wouldn't you only need to show the results from the ending location? If
the user managed to pan over 5 screen widths in under a second, don't
you only care about what would be visible when the panning is stopped?
(I'm trying not to make any assumptions about your app, but.. :) )
So, if that is the case, maybe a short delay before you trigger the ajax
routines to get your pins. Pseudo logic for that might be:
pan start
- clear old time out value (if any)
- set new timeout
timeout
- get pin data for current area
- render pin data
And then if you set the timeout to something reasonable - maybe 500 ms?,
then you end up sending much fewer ajax requests, and dealing with
fewer pins as well.
If needed, you can still combine this approach with the "queue" idea.
But instead of queuing ajax requests, queue the areas that need to be
retrieved on each pan, and then when the timeout fires pass that data to
your server side code.
Just a thought... and maybe easier to code than ajax queues.
But I guess the answer you are looking for is "no, jQuery does not have
anything out of the box to do what you want". Nor should it, in my
opinion.. :) There may be a plugin for this sort of thing, but I
haven't seen one (yet).
Shawn
partner56290674 wrote:
the "flooding the server with calls" is a non argument. If you don't
want to do that, then you need to redesign your server side code to
accept a single request to give you all the data you need
Not true .. well at least I don't see it as that. I have no probs with
multiple calls hitting the server at once. If you can't write scalable
code, then that's your bad luck and out of scope of this discussion.
This leads to this quote:
As for "queueing up ajax requests", doesn't that defeat the purpose of
an asynchronous environment? Afterall, the end result of queuing up
requests is a synchronous routine. Why not just load another page that
does everything you need?
and
But,
if we cannot clearly define what you are trying to do, then we cannot
clearly tell you if it's in core jQuery, or in a plugin.. :)
Also not true .. actually far from it .. and i'll use the example i
want to do, to illustrate this.
I'm doing some Ajax calls with my google maps, so when the map is
panned, an ajax call hits our server to retrieve some data to show ON
the map. Easy. Now, the problem lies when users pan-pan-pan-pan-pan ..
ie. do lots of pans in quick succession. Now having 5, 6 or even 10
hits to our server is not a problem. It gets messy when the browser is
trying to download lots of google map tiles AND then render hundreds
of pins (our results from the ajax) .. especially if all the results
are coming back async. So to help relieve the pressure on the client
side, by having an ajax QUEUE client side, the results will only be
rendered one at a time. By default, the browser will try to hit the
server the with the max number of connections to the same domain (eg.
Internet Explorer is defaulted to 2 connection, prior to IE8 i think).
that's what i'm trying to do and why i believe it's important.
It's also for scenario's with latency issues ... check this vid out
(and ignore the fact that it's about script.aculo.us):
http://www.phppatterns.com/stuff/latency.html
does that make more sence?
-me-
