I had a case where I had to wait for n records to come from the server. They all had the same callback, which incremented a counter.and checked to see if this load was the last one. It worked, but I have thought about giving the whole lists of requests to the server at once and having the server put together one large response instead of n small ones.
I've had other cases that were more complex where I used a bitfield instead of a bunch of logic to see if the required pieces had come in yet. I've not come up with anything I like in jQuery animation-wise. When it's just one thing I'm animating in jQuery, I'm happy. When it's more, I end up with a big mess. I'm not sure what I'm looking for, but I'm really starting to hate jQuery's nested animation system because it's such a pain to change things around once you've done the work. On Mar 7, 2:19 pm, Shawn <[EMAIL PROTECTED]> wrote: > This plugin was suggested in another thread: > > http://plugins.jquery.com/project/ajaxqueue > > While it's close, my initial read of it suggests it doesn't do quite > what we're looking for here. I'll have to play with it to be sure though... > > Shawn > > Hamish Campbell wrote: > > Sounds like some sort of ajax queuing plugin is in order. Would have > > to be more complex than animation queues. > > > eg, queue constists of a 1-d array. Each element in the array can be a > > request, or an array of requests (that execute simultaneously). The > > queue pops the first element, performs the call (or calls), checks for > > completion then pops the next one. Errors return the queue position, > > or perhaps there is an array of error callbacks? > > > On Mar 7, 1:30 pm, Shawn <[EMAIL PROTECTED]> wrote: > >> I have a similar situation and am watching this thread in hopes > >> something useful may come of it. > > >> What I've done for now is the nested calls. I use a common > >> errorHandler() function that takes in the element to show the message > >> with and the message itself. The message tends to be the .responseText > >> of the XHR object more often than not. But this still feels clumsy. > > >> What I've considered doing is to create a temporary structure that would > >> contain flags for each of the sub processes. The success function for > >> each sub process would set its flag as being "complete" and then call > >> the final update function. This final update function would check each > >> of the flags and when all are set do whatever final processing (if any) > >> is needed. > > >> For instance, I need to a) get a list of employees, b) get a list of > >> tasks for all employees, c) render a table for the employees tasks and > >> apply some code to give the table a fixed header and column. I already > >> have existing routines to get the employees and tasks, so can reuse > >> these here. So my code may potentially look like this: > > >> var mydata= { > >> flags: { employees: false, tasks: false }, > >> employees = [], > >> tasks = [], > >> render: function () { > >> //don't continue if we don't have enough data > >> if ( !mydata.flags.employees || !mydata.flags.tasks ) { return; } > > >> //code to render the output goes here. > >> ... > >> } > > >> }; > > >> $.ajax({ > >> url: "getEmployees.php", > >> dataType: "json", > >> success: function (json) { > >> mydata.employees = json; > >> mydata.flags.employees = true; > >> mydata.render(); > >> } > > >> }); > > >> $.ajax({ > >> url: "getTasks.php", > >> dataType: "json", > >> success: function (json) { > >> mydata.tasks = json; > >> mydata.flags.tasks = true; > >> mydata.render(); > >> } > > >> }) > > >> obviously this is not throughly thought out yet, and has room for > >> optimizations (I don't think the flags are really required if you just > >> check the data properties instead). But what this would allow is the > >> two ajax requests to be run concurrently and still have the same output. > >> Which ever Ajax request finishes last fires the rendering (and it > >> doesn't matter which). > > >> The nested approach would take twice as long (by may be more reliable?) > >> as the second request isn't made until AFTER the first has been > >> completed. This may be a moot point for this sample problem, but I know > >> I have a couple places where 4 or 5 Ajax requests are needed to complete > >> one task. > > >> The problem here is that event handling is not taken care of > >> automagically. Each Ajax request would need to handle this itself. But > >> this entire process could in theory be wrapped up into a single > >> function. I guess the real question is if that function can be > >> abstracted enough to make it generic. Right now, I don't see how. > > >> I don't think this idea is revolutionary or anything. Probably kinda > >> obvious and/or flawed. But perhaps it'll get you (us?) moving in a > >> positive direction. > > >> Now I'm curious though and want to try out some things... I'll report > >> back if I have any success... > > >> Shawn > > >> h0tzen wrote: > > >>> On 5 Mrz., 15:40, J Moore <[EMAIL PROTECTED]> wrote: > >>>> wouldn't nesting the methods work? e.g. > >>> unfortunately not as some methods have to be invoked in parallel. > >>> generally exactly this nesting looks fine with no real code behind > >>> but it is just cruel if you imagine having error-handling, rollbacks > >>> and business logic etc within. > >>> what im looking for is some pattern abstracting the async-callbacks > >>> or just a real-world example/solution of someone having the same > >>> issues with logic involving multiple, dependent ajax-calls. > >>> thanks, > >>> kai- Hide quoted text - > >> - Show quoted text -
