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. One call, one response then. But that's a server issue. And there are performance/modularity issues with that approach (depending on scale/volume). Any other way means the client making multiple requests from the server.

As for "displaying" them as they come back to the user, nope. Only once ALL the requests are completed is the further processing done. But this meets MY specific needs. I had a situation where I needed 3 distinct ajax calls, but needed the results of all 3 before I could render the output properly. My approach handles the possibility of the responses not being in order.

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?

Your use of the phrase "queue" may be accurate, but I think you are using it slightly differently than I interpreted it in this case. 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.. :)

Shawn


partner56290674 wrote:
what your doing there Shawn is still flooding the server with ajax
calls, and displaying them as they come back to the user. What happens
if some requests come back out of order (eg. latency)?

now if u switched it around .. that might be usable...

so there's nothing built in to jQuery? Is anyone else queuing up their
ajax requests?

Reply via email to