Many commands to control the model and the state machine

[serka]

Question: How do people suggest dealing with moving the FSM through its states while loading resources?

My details:
In my app, I have a number of remote resources to fetch (other SWFs, some XML, etc). A common use case is:

• Transition to State S1
• Model should load data
• Transition to State S2 if successful, S3 if failed

I find myself registering a command to the state change, the model's success notification, and the model's failure notification. Each command has almost nothing more than a line or two of code and with several such cases I'm fearing an explosion of commands and a difficult-to-manage fragmentation of logic.

I was considering a creating a mediator with no view component and having it listen to all the notifications I have such commands registered to or perhaps one mediator for every state. The upside is that all the code related to moving the state machine around will be in one place. On the other hand, it feels like I'm hacking something in where it shouldn't be (mediator that mediates nothing?).

[serka]

I've been looking through the SOAMusicPlayer source and PlaylistModuleMediator in particular seems to deal with the same issue I mentioned in my first post. That projects deals with the issue by having a command (ConfigureCommand) initiate the call on the proxy (ConfigProxy.configure()), then PlaylistModuleMediator is responsible for sending the state machine action in response to a success or fail.

My follow up questions to my first post are:
1) Is what SOAMusicPlayer does a recommended practice?
2) PlaylistModuleMediator confuses me. I expected it to mediate the module, but it never touches its view component after construction and appears more interested in two proxies (ConfigProxy and NavProxy). Did it just become a convenient place to place "global-ish stuff" that did not belong in the other mediators and could not be done in a command because a persistent object was desired? Unless I've missed something, this would make it an example of the "mediator that mediates nothing" in my previous post.

[puremvc]

I was considering a creating a mediator with no view component and having it listen to all the notifications I have such commands registered to.

I believe you're on the right path here.

On the other hand, it feels like I'm hacking something in where it shouldn't be (mediator that mediates nothing?).

Not really. It is mediating communications between the Proxy and the StateMachine. The fact that a mediator has a convenient way to handle mediating view components doesn't mean that they can't also be used to mediate communications between other PureMVC actors.

Is what SOAMusicPlayer does a recommended practice? (...PlaylistModuleMediator is responsible for sending the state machine action in response to a success or fail...)

Yes. Regardless of what actor triggered the Proxy to make a call, the response should be sent from the proxy as an ordinary notification, NOT a StateMachine.ACTION notification. The maximum benefit of MVC is achieved in a rich client when the Model is completely reusable. Thus it should not know anything about the StateMachine or the actions set up for this application.

So, you're left with your original dilemma of

An explosion of commands that just turn around and send StateMachine.ACTION notifications. Smelly

OR
A Mediator that is registered for everything and does the translation. Since that's the normal job of the Mediator (albiet usually translating events to notifications), it is still a perfect responsibility match.

PlaylistModuleMediator confuses me. I expected it to mediate the module, but it never touches its view component after construction and appears more interested in two proxies (ConfigProxy and NavProxy). Did it just become a convenient place to place "global-ish stuff" that did not belong in the other mediators

Yep, that it did. It wasn't doing much and ended up handling a few of these relay actions.

As for the module, it's just keeping that in a pouch. It could just have been plumbed onto the end of the pipe and forgotten about, but it's easier to troubleshoot using the debugger this way. At a breakpoint, you just drill down through the facade, view, mediatorMap, PlaylistModuleMediator and bang, there's the module.

-=Cliff>

[serka]

Thanks!