AsyncToken does work well for relatively simple cases - like communicating what to do after the model completes an operation. However, when you need to schedule several things to happen in order, it gets really dicey. Either your token takes on a life of its own (essentially becoming a command class itself), or you end up trying to follow notification responses through several iterations to figure out what the actual result of the original call will be.

Let's take an example of the startup of an application which needs to get information from multiple sources. My goal is to centralize the list of things that need to happen in order so that token chasing is kept to a minimum for anyone later analyzing the code.

Let's assume for the purposes of discussion that this is happening in Flash instead of Flex, and that we want to try to maintain the "pure actionscript" principle and avoid Flex-specific constructs.

Let's say my theoretical application has to:
1)Load data from flashVars into the model to get the URI of its datasource (synchronous)
2)use the loaded URI to download an XML data file (asynchronous)
3)use the information in the loaded data file to download a splash screen (asynchronous)
4)fade in the splash screen (asynchronous)
5)parse the rest of the loaded data and generate navigation from it, using assets referenced in the data file (concurrent asynchronous with #4)
6)when both 4 & 5 are complete, display landing page.

Using AsyncToken pattern instead of a Command pattern to perform the list above is possible, but trying to follow the chain of tokens and responders would get very confusing for anyone analyzing the code later on. Especially for something like this, where the model is acting somewhat like a view, it seems to me that a Command pattern is able to orchestrate asynchronous sets of tasks much more elegantly. I say the model is acting like a view in this case because the application needs to respond appropriately to server (or other asynchronous) actions much like it responds to user actions.

I'm not suggesting that the controller talk to services, but instead I am suggesting that the command classes of the controller be better able to orchistrate sets of actions which may branch and may include processing time. For example, what if the user is able to create a macro that the program needs to execute? or What if the application has a socket open to react to events from other users on a distributed network? or What if the user needs to fill out a wizard to perform some task, where each step of the wizard is dependent on the previous step?

I know that PureMVC isn't FrontController, but it seems like an async-enabled command class would give you the best of both worlds. I don't think it has to act like Cairngorm's SequenceCommand where a delegate (similar to a proxy) has to call "nextCommand()", but it seems like there is a minor improvement to MacroCommand which could handle some of these cases better. Maybe an addAsyncSubCommand( IAsyncCommand ) would work, making it so that an IAsyncCommand responded to a particular notification from a proxy.

Essentially, what I'm after is a way to serially execute commands even when some commands are asynchronous. It is a common task for me, and in my first PureMVC app, even the simple application loading process paraphrased above got unnecessarily difficult to follow with the existing command class. IMHO, commands are the best place to set up orchestrations like that, but when you can't have a command that survives throughout an asynchronous process, sequencing gets much more complex and you have to worry about things like race hazards much more.

I understand how an asynchronous chaining command might not make it in to the framework, and I see why the execute command is final, but it would be nice if there were a way to encapsulate the sequence within the command.

In my own application, I did just have my proxy send out another notification. However, sometimes it is certainly nice to have a centralized command chain without having to chase a whole trail of asynchronous proxy responses, or put in a bunch of transient "what I'm supposed to do after the webservice call returns" variables in the model. Commands are designed to be where big things involving lots of application-wide stuff can be centralized, why limit them to being synchronous things?

I think a good example is 'lazy authentication'. A user deep links to a part of the application where authentication is necessary. A command is issued to 1)check authentication via webservice, 2)modify the model to update the view to complete their request. If the webservice call in #1 fails, standard authorization comes up, eventually calling nextCommand() once a successful authorization takes place. The authorization component only has to know to call nextCommand(), and the model doesn't have to have tons of transient state flags and logic to store what was supposed to happen next.

I'd say the existence of MacroCommand essentially justifies the general pattern, but in real world use, the subcommands of a MacroCommand class can (and frequently should) depend upon data retrieved asynchronously. So, any chance a SequenceCommand pattern could be introduced to basically do the nice architectural things for asynchronous subcommands that a MacroCommand does for synchronous subcommands?

I'm wondering why the base constructor of proxy takes both NAME and data arguments, while the base constructor for mediator takes only a viewComponent argument, forcing the developer to override getMediatorName. Seems like it would be easier to do them both the same way.

I'm writing this because I just ran in to a case where retrieveMediator was returning null and it took me a bit to figure out why. Turns out I didn't override getMediatorName, thinking I was passing NAME in to the super call in my constructor.

Why is it arranged this way?

Now I know it is generally best to avoid referencing a mediator from elsewhere, but I'd rather spend time refactoring to avoid directly referencing a mediator than figuring out why I can't get the mediator's reference!

Sean

Maybe I was envisioning too much implementation in the Mediator. Nevertheless, I don't like using switch statements for that purpose, so I'll see what I can do with a subclass. Of course, this being my first PureMVC project, I'm hesitant to do too much before I have a really good grasp of the framework.

I'll post what I end up doing to overcome my switch statement allergy.

Looking at the macroCommand class, I'm wondering what the recommended practice is for chaining asynchronous commands, as macroCommand appears to just call the next command once the execute method returns, which may not actually be the end of the command.

When I'm getting something from the server, I'm typically going to have a callback which will need to execute before I want the next command to fire. I'd rather not couple all asynchronous commands with a specific command to execute next, as this often changes depending on the context.

I believe that Cairngorm's SequenceCommand handles this pretty well, and I wondered if anyone had any thoughts on implementing something like that in PureMVC. I'm guessing that using SimpleCommand with a payload that includes the command to call next would work, but I did like the simplicity of calling executeNextCommand() when my asynchronous command completed, and I like aggregating my FIFO command stack in a 'meta command' rather than just running it through a notification payload.

I'd try overriding the macroCommand's execute function, but it is declared final for some reason. Is there a way to easily override macroCommand to account for asynchronous subcommands, or is that execute function final for a reason?

Sean

So, I'm just getting in to PureMVC and one thing that struck me as being odd was the way notifications are subscribed and handled. I'm not a big fan of handling program flow with a big case statement - to me it wreaks of procedural programming and begs for refactoring to improve reusability and maintainability (without hurting readability).

I know that in IIBP, Cliff talks about how it seems more readable to differentiate events from notifications by the fact that notification handlers are in this big case statement in handleNotification, but that sounds to me like the architectural choice is being affected too much by the event implementation inside Flash/Flex. It could be just as easy and readable to handle events from the viewComponent with "onEventName" and to handle notifications with "handleNotificationName".

The other aspect about this construct that troubles me is that in your subscriber (the Mediator implementation) you're handling the actual subscription and implementation of its handler separately such that it is not noticeable at compile time. For instance, you can easily subscribe to ApplicationFacade.SEARCH_FAILED without implementing a means to handle that subscription, potentially leading to unnecessary subscriptions down the road, and generally making it harder to maintain.

What is the logic behind not providing a reference to the implementation method during the subscription? That way if the implementation is removed, the subscription will be invalidated in a way detectable at compile time. It also seems like handling different notifications through different methods allows those methods to be more easily reused down the road.

I think another major reason to avoid the single notification handler with the big switch statement is that it tempts the developer to add pre- and post-handling code in handleNotification. Doing things that way would seriously bind any notification handling logic to that one component, and make that component's implementation very rigid. For example if you had 99 cases in a switch statement that were happy with the preprocessing that occurred before the switch statement, and 1 notification handler that wasn't, you're basically setting yourself up for 99 refactorings or one poorly chosen 'if' statement.

If I do go with PureMVC, I'll probably end up subclassing Mediator to obfuscate listNotificationInterests and handleNotification in favor of a more event-type dispatcher within the mediator class. It isn't good to have event dispatching going on within each mediator, but I'm not sure what other components would need to be changed to do it the right way.

Sean