PureMVC Architects Lounge

Announcements and General Discussion => Architecture => Topic started by: sebboon on February 19, 2010, 01:35:48



Title: RemoteObject and MacroCommand - Responder VS EventListener
Post by: sebboon on February 19, 2010, 01:35:48
Hi everybody,

I've got another tortuous question !!

Currently I'm using addEventListener to add a callback function to a remote object method call like this :

:
myRemoteObject.myMethod.addEventListener(ResultEvent.RESULT, myCallBackFunction);

Recently I need to create a Synchronous MacroCommand, in which some sub commands need the result asynchronously asked to the server of the previous command.

To perform this task I use the AsyncToken return by the method call of the remoteObject.
It works quite well except for one thing !

:
var token:AsyncToken = processCommandClass(this._subCommands.shift(), notification);
token.addResponder(this);

Each subCommand have a asyncToken attribute.

A remote object method called which have an event listener and a responder attached on its asyncToken, will be processed in this order :

1 - Responder
2 - Event listeners

But in my synchronous macro command when I pass to the result method of my responder I have to restart the queue of the macro command, and then I pass into the second command before being passed into the eventlistener of the the first one.....


I found an ugly workaround, but it's not really convenient, I have to always use Responder on asynToken and never attached eventListener to a method. (therfore I have to rewrite all my proxies for only one specific macroCommand in order not to have heterogeneous proxies ...)

==> Do you know a way to let the event listener being processed before the responder ?

Or

==> Do you know a way to relaunch a command asynchronously to let the eventListener being processed before to call other sub command ?

Thanks for your replies :D


Title: Re: RemoteObject and MacroCommand - Responder VS EventListener
Post by: puremvc on February 22, 2010, 07:29:11
It's really better if you use Proxies to do the communication with the service. They are long-lived actors that are intended to encapsulate the domain model, including interaction with remote services on behalf of the application. This keeps all service interaction in the Model tier where it can easily be packaged up and reused in another application.

-=Cliff>