Mark,
I've used to the same approach you describe but I didn't implemet
failureFunc. This facade, in my case, detect a failure and display
a message error. This approach take an advantage that you don't take
care any more for failures and it will always be treat in the same way.
This is a example method in my facade
public function formDeleteAccount( listener: Function ): Operation
To call this method you can use
formDeleteAccount( <handler> ).send( <params> )
The send method return a AsyncToken and you can add more "listener"
or put other params token for handler function.
There is other methods like it:
public function filterByText( listener: Function, text: String ): AsyncToken
In this case, we use the compiler to force the correct params. I like
this second approach
and we will convert all the code to use it.
If you have an interesting, I can send you all the code. But believe,
I don't know if it is the
best practice, but, for my problem, it run very well.
--
Marco Catunda
On Wed, Dec 10, 2008 at 6:34 AM, Mark Carter <[EMAIL PROTECTED]> wrote:
>
> 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.
>
> What say you all - good or bad practice?
> --
> View this message in context:
> http://www.nabble.com/Best-practice-for-calling-asynchronous-functions--tp20930596p20930596.html
> Sent from the FlexCoders mailing list archive at Nabble.com.
>
>
