Support Staff2 Posted by Shaun Smith on 13 Sep, 2010 05:46 PM
Instead of using a custom Notification scheme (like PureMVC), Robotlegs simply uses a native flash IEventDispatcher to communicate between objects. To execute commands when a given event is fired you'd use the ICommandMap:
// Wherever you do your configuration (third param is for type-safety):
commandMap.mapEvent( SomeEvent.BOOM, SomeCommand, SomeEvent );
// Somewhere else (in a Mediator, Command, Model or Service):
eventDispatcher.dispatchEvent( new SomeEvent(SomeEvent.BOOM) );
Mediators and Actors have a shortcut for event dispatching:
Use dispatch(event) (from Mediator, Command, or Actor) to send an
event into the event bus. The event will trigger any commands that are
mapped to that event. Also, any mediators that have mapped a listener
for the event will pick it up.
Support Staff5 Posted by Shaun Smith on 14 Sep, 2010 11:30 AM
It looks OK, but why do you need the Switch statement? The nice thing about event handlers is that you can subscribe directly to the thing you are interested in. A switch generally means that your handler/command is doing more than one thing - which is a sign that it should be broken down into smaller, more focused handlers/commands.
When you do this: commandMap.mapEvent(EventClass.TYPE, CommandClass, EventClass); the Command will only be constructed and executed for that specific Event and type, so again, no need for a switch.
Can you explain why you're switching based on Event.TYPE?
The Command should only be fired in case of the event you were looking for... so that switch shouldn't be necessary.
If you've got the same command firing for 2 different events, and you need to switch on type, I'd suggest separating that to two different commands.
If the bulk of the work in the Command is shared, and only a small bit is different, and this is what you're switching on type, I'd maybe pull the shared behaviour out into a class that helps the command - depends on your preference, but on the whole switches / ifs are a sign that logic might be better handled at a higher (architectural) level.
(I'm assuming the public var event:EVENT is a typo and should really say public var event:EventClass.TYPE etc)
It's exactly the case, I want my command handler to handle multiple events, this events are simple and for me it just seems a bit long winded to create lots of command class to handle this events. When I can have a central command handler to handle this with just a switch.
This approach is kind of defeating the purpose of the command pattern, which is that each individual piece of 'action' is encapsulated (along with the complexity associated with it).
Not that it won't work, or can't be done, but it isn't what was in mind when this framework was designed, so while it might work, you lose the benefits of encapsulation of complexity, and of using a well understood approach that others can quickly pick up.
You're really treating your Command as a Controller. Which makes it easier to break things unintentionally, harder to unit test and so on.