Intermodular communication (Best)Practice

zuzu's Avatar


02 Mar, 2013 08:47 PM


I am currently converting a RL1 project to RL2 and while everything is working I am not quite happy with how I set up my inter-modular communication. My original project had a modular structure but since I underestimated the amount of wiring everything was mapped to the main context. During the rewrite I now gave every module its own context, config and mediator.

The mediator listens for events interesting to the module from the main context and forwards them over the context view into the module. While I am not sure that’s a proper approach I see no real problem with it either. What seems troublesome is my way to broadcast events back out in the main context. Originally I wanted to add a listener to the context view to route events back out over the mediator, but it seems the context view is more like a view than I thought for that didn’t work. Currently I am accessing the module context through a command and use injector.parentinjector.getInstance() to use the EventDispatcher of the main context, but it feels odd to use the context like this in a command.

Then I thought it might be the better to forgo mediators and just override the event dispatcher of the module with the one from the main context during configuration – however that doesn’t seem to solve my problem either, as the command the event is mapped to in the module doesn't get executed when the event fires outside the module itself. Maybe I need to override something else as well?

Overall I am a bit clueless what the best practice approach for inter modular communication would be. I saw there is a ScopedEventDispatcherExtension, but since I have no intention to have different communication channels it doesn’t seem as if I would need it for basic communication.

I would appreciate it, if someone could give me some pointers, particularly how to send events outside the scope of a child context.

  1. Support Staff 1 Posted by Shaun Smith on 03 Mar, 2013 09:44 PM

    Shaun Smith's Avatar

    Hello Zuzu,

    Unfortunately there isn't an official approach to this just yet.

    The challenge is that each context get its own isolated Event Dispatcher, so if you are wanting to dispatch an event from the Shell and have a Command fire inside a Module, you need to relay the event somehow.

    I'd really like to come up with an Extension to simply event relaying. One that doesn't rely on mediators or digging into the parent's injector.

    As for the ScopedEventDispatcherExtension, you might need to use it in the end anyway. Even though you don't intend on having separate communication channels, it's the only way to "share" secondary dispatchers between a Shell and its Modules. Otherwise all you have is completely isolated dispatchers for each context.

    I'm working on something but struggling a bit with the API and preventing circular relays (causing infinite event loops).

    In the meantime, here's how you might do it manually:

    1. Install the ScopeEventDispatcherExtension into the Shell and Module contexts. By default this will map an IEventDispatcher named "global" into the Shell context which the Modules will inherit.

    2. Create a config for setting up the relaying

      class MyConfig implements IConfig
        public var local:IEventDispatcher;
        public var global:IEventDispatcher;
        public function configure():void
          // relay an event from the global to the local dispatcher
          global.addEventListener("blah", local.dispatchEvent);
    3. Dispatch specific events along the global dispatcher

      public var global:IEventDispatcher;
      global.dispatchEvent(new Event("blah"));

    If you have any ideas for a nicer API for such a mechanism please let me know. I'd like to get this sorted before the RL2 release (which is pretty soon).

  2. 2 Posted by Gustavo on 04 Mar, 2013 02:30 PM

    Gustavo's Avatar

    Hello Shaun & Zuzu,

    Is there a similar solution for signals?

    I am now mapping the Signals to the commands on the correct ISignalCommandMap because I manually find with of the children injectors to use. But I would be gratefull to have a similar temporary solution as the ScopeEventDispatchers for the Signals.

  3. Support Staff 3 Posted by Shaun Smith on 04 Mar, 2013 08:33 PM

    Shaun Smith's Avatar

    Hi Gustavo,

    RL won't bundle any official Signals support until Signals reaches a stable (v1.0) release.

    In the meantime you could try your hand at creating your own ScopedSignal extension. The ScopedEventDispatcherExtension is pretty simple:

    Let us know how you get on.

  4. 4 Posted by Gustavo on 05 Mar, 2013 06:57 AM

    Gustavo's Avatar

    Allright !

    I'll let yo u know how it goes

  5. 5 Posted by Gustavo on 05 Mar, 2013 07:58 AM

    Gustavo's Avatar

    Well, The first problem I'm encountering also makes me wonder how is this supposed to work on the IEventDispatcher version.

    As I can see is the extension mapping the EventDispatcher to a newly created instance when initializing. And is mapping it with the name/s give ('global') by default.

    From what I can see, and please correct me if I'm wrong, this means that only 1 event dispatcher can be named as 'global' right?

    This might even be pulled-off with a global super powerful EventDispatcher but I believe it can't go so good when using one ISignal.

    I'm now thinking on an alternative approach, and will be posting.
    If you have any ideas please let me know.

  6. Ondina D.F. closed this discussion on 08 Apr, 2013 10:06 AM.

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

Keyboard shortcuts


? 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