Command Notificitation

brucealmighty 's Avatar

brucealmighty

13 Sep, 2010 05:25 PM

Hi

I am new to RL, coming from PureMVC I figured I'd build small projects with RL...

In pureMVC, I normally have ApplicationConstant then use "sendnotification()" which I can pick up anywhere from within the app. Especially in the Command notifictication.

How would I go about this process i.e

Send notification from Mediator and have the Command listen to it.

I can elaborate more if it's not clear enough.

Thanks

  1. Support Staff 1 Posted by Shaun Smith on 13 Sep, 2010 05:46 PM

    Shaun Smith's Avatar

    Hi there,

    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:

    http://github.com/robotlegs/robotlegs-framework/blob/v1.1.2/src/org...

    // 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:

    http://github.com/robotlegs/robotlegs-framework/blob/v1.1.2/src/org...

    Hope that helps! Let me know if you need more info.

  2. 2 Posted by Paul Robertson on 13 Sep, 2010 05:50 PM

    Paul Robertson's Avatar

    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.

    Mapping commands:
    commandMap.mapEvent(EventClass.TYPE, CommandClass, EventClass);

    Mapping listeners (in mediators):
    addContextListener(EventClass.TYPE, handlerFunction, EventClass);

    (which is just syntactic sugar for this, which you are more likely to
    encounter in examples)
    eventMap.mapListener(eventDispatcher, EventClass.TYPE, handlerFunction,
    EventClass);

    Paul

  3. 3 Posted by brucealmighty on 14 Sep, 2010 11:19 AM

    brucealmighty 's Avatar

    Thanks for the feedback....

    I understand that approach and I have implemented it thanks.

    I am not sure if this is a good implementation but the way I am implementing it now is to have:

    Mapping commands:
    commandMap.mapEvent(EventClass.TYPE, CommandClass, EventClass);

    Mapping listeners (in mediators):
    addContextListener(EventClass.TYPE, handlerFunction, EventClass);

    In the CommandClass:

    [Inject]
    public var event:EVENT;
    
        override public function execute():void {
            switch( event.type )
            {
                case EVENT.EventStaticType: {
    
                }
            }
        }

    This implementation seems to work fine and its sort of similar to PureMVC, I wonder if anyone as any opinion on it.

  4. Support Staff 4 Posted by Shaun Smith on 14 Sep, 2010 11:30 AM

    Shaun Smith's Avatar

    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.

    More info on the "Switch Smell": http://c2.com/cgi/wiki?SwitchStatementsSmell

  5. 5 Posted by Stray on 14 Sep, 2010 11:39 AM

    Stray's Avatar

    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)

    Hope that's helpful,

    Stray

  6. 6 Posted by Stray on 14 Sep, 2010 11:39 AM

    Stray's Avatar

    Shaun beat me to it. (But it's always nice when Shaun has the same reaction as I did... phew!)

  7. 7 Posted by brucealmighty on 14 Sep, 2010 11:42 AM

    brucealmighty 's Avatar

    Thanks for the swift reply

    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.

  8. Support Staff 8 Posted by Shaun Smith on 14 Sep, 2010 11:50 AM

    Shaun Smith's Avatar

    @Stray: haha! I prefer it when our reactions are both orthogonal and valid :)

    @dtads: If the thing that you are switching on is unlikely to change/grow then perhaps using a Switch is OK. Usually though, switches becomes maintenance/development pain-points as applications grow.

  9. 9 Posted by brucealmighty on 14 Sep, 2010 11:57 AM

    brucealmighty 's Avatar

    Cheers Shaun and Stray

  10. 10 Posted by Stray on 14 Sep, 2010 12:01 PM

    Stray's Avatar

    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.

  11. 11 Posted by Stray on 14 Sep, 2010 12:04 PM

    Stray's Avatar

    @Shaun - orthogonal and valid is definitely a win!

  12. 12 Posted by brucealmighty on 14 Sep, 2010 12:13 PM

    brucealmighty 's Avatar

    Well this is a small game with tight deadline relatively small scale project, hence I thought I would use the opportunity to sample the RL framework.

    But with that in mind, I didn't really see that much sample for me to get an understanding on RL notifitication and control.

    Perhaps you can show/send me a link or show a simple real world sample, with the encapsulated approach, I think it would benefit people like myself, who are new to RL framework.

    BTW I am using Flash

    Cheers :-)

  13. 13 Posted by Stray on 14 Sep, 2010 12:24 PM

    Stray's Avatar

    That's interesting (that you didn't see samples) - I'm wondering whether you just missed them, or whether they're not adequate? Let us know.

    Did you check out:

    http://www.robotlegs.org/examples/

    .. all feature the conventional use of the CommandMap.

    There are even more on github:

    http://github.com/robotlegs/robotlegs-demos-Bundle

    In particular, check out the commands in the imagegallery example:

    http://github.com/robotlegs/robotlegs-demos-Bundle/tree/master/FlickrImageGallery/src/org/robotlegs/demos/imagegallery/controller/

    Hope these help,

    Stray

  14. 14 Posted by brucealmighty on 14 Sep, 2010 02:25 PM

    brucealmighty 's Avatar

    I saw most of the samples, but the ones that helped me get started, especially using flash ide, was the clock sample and the helloworld.

    I think more sample is needed especially for flash ide.

    A suggestion would be a simple navigation system, moving from introview -> mainview -> exitview. While passing data through.

    Since you mentioned image gallery I have a futher look into it and the way the commands are used.

    Cheers

  15. 15 Posted by Stray on 14 Sep, 2010 02:40 PM

    Stray's Avatar

    Thanks for the feedback.

    It's time consuming to do demos, but I'm sure they'll continue to grow as and when people get the time to contribute.

    Stray

  16. 16 Posted by brucealmighty on 14 Sep, 2010 03:37 PM

    brucealmighty 's Avatar

    I'm sure it will, well I plan to use RobotLegs more often for my future project.

    You guys are doing a fantastic job, especially with the support.

  17. Stray closed this discussion on 12 Feb, 2011 10:59 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac