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

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