Frank W. Zammetti wrote:
Michael Jouravlev wrote:
Off the top of my head, I
would think you would need to set up a timer, and when the responses
come back, instead of processing them on the spot in the callback,
instead set a flag in the call structure that says "yes, this request
completed, but don't process it until the previous one completes"...
fire the timer every half a second or something like that to examine all
the call structures in the queue and fire them as appropriate.
Nah, this won't work. I need to fire second XHR only after the first
one returns. The reason is that first request updates server status
and I want second request to pick it up. I will think about firing
requests on timer. Seems like this is the only way. Or maybe I can
stick request number into request parameters, and reorder requests on
server? In this case I will need total number of requests too. TCP/IP
somehow does this kind of thing, right? Should have to read more about
it ;-) In my case I always fire *all* requests, so TCP/IP should be a
good exaple to look at.
Actually, this makes it *easier*... I thought you needed to fire
multiple requests simultaneously, but only handle their response in the
order they were fired.
If you simply want to be sure request #2 does not fire until request #1
returns, try this... Build up the queue like I mentioned, it's just a
FILO stack... periodically in response to a timer, look at the top item
on the stack. If it has not returned yet, keep waiting. If it has
returned, pop it and fire off the next item in the stack. How will you
determine if it has returned yet? Simply set some flag in your callback
to indicate it. That's actually not so hard (unless I'm missing
something, which is of course entirely possible!)
Probably not a trivial exercise, but should be doable.
I hope so. I will keep this discussion in public list in case someone
else decides to chime in.
Give what I suggest here a try, I *think* it will do the trick :) And
the code in AjaxTags in JWP should be very relevant, you'll just alter
what's done in the callback (heck, you could actually DO this with
AjaxTags just by writing yourself a SerializingResponseHandler).
Frank
I still think it'd be easier to use the XmlHttpRequest's callback
function to launch the next request in the queue rather than polling
with a timer and requiring the callback to record state for the polling
to query... Something like (pseudo-code):
var q = [];
function processQ() {
function callback(req) {
if (req failed) throw "XmlHttpRequest failed!";
processQ();
}
if (q.length > 0) {
var req = createReq(q.pop(), callback);
...
req.send();
}
}
...
q.push(req1);
q.push(req2);
processQ();
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
