--- In [email protected], "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > ----- Original Message ----- > From: "Mark Carter" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, December 10, 2008 8:34 AM > Subject: [flexcoders] Best practice for calling asynchronous functions? > > > > > > In my app, I make a wide variety of XML-RPC calls. Now, to avoid having to > > add/remove listeners all over the place, I've created a class (facade?) > > with > > functions like: > > > > function save(xml:XML, successFunc:Function, failureFunc:Function):void; > > function load(id:String, successFunc:Function, failureFunc:Function):void; > > > > Note, the class' state does not change when any of these functions are > > called. > > > > The class makes the necessary XML-RPC call and listens to the appropriate > > events before calling the relevant success or failure function. The class > > guarantees that either the successFunc or the failureFunc will be called > > at > > some point (but never both). > > > > This makes my calling code very neat: > > > > save(myXML, function(id:String):void { > > Alert.show("Successfully saved XML using id: " + id); > > // now do the next step > > }, function(msg:String):void { > > Alert.show("Failed to save because: " + msg); > > // now rollback > > }); > > > > One obvious drawback of this is that its not so easy to add multiple > > listeners to, say, the save operation. But, in my situation, I never need > > to. > > I would have thought it was very easy to add multiple listeners for the save > operation - just have the single successFunc call multiple functions. The > real problem may be that writing inline functions could make your code > difficullt to follow if they get too complex - I'd probably use inline > functions only for trivial cases. > > Effectively you've replaced event listeners with callback functions. I don't > see the harm in it and I know a lot of people like using callbacks rather > than full blown event handling. > It does look quite neat and enforce cleaning up listeners.
Another way to handle it is with a token. The token "rides" the event, so there's no cleanup to be done...Once the event is handled the reference to it goes away, and so does the token and its responders. http://flexdiary.blogspot.com/2008/11/more-thoughts-on-remoting.html
