Home → Suggestions →

combined use of SignalContext and ModuleContext

• Edit

tom

01 Jun, 2010 10:16 PM

i'd love to use both in the same project.

1. 1 Posted by Stray on 01 Jun, 2010 10:26 PM

   

   I do :)

   I simply hacked my module context to be a ModuleSignalContext.

   It's no more sophisticated than:

   public class ModuleContext extends SignalContext implements IModuleContext

   We talked about some sort of boot strapping / decorator thing for special contexts, but for now the roll-your-own approach is so easy that it's not a big deal.

   • Edit

2. 2 Posted by tom on 01 Jun, 2010 10:34 PM

   

   what a stupid question of mine :) thanks a lot.

   • Edit

3. Support Staff 3 Posted by Joel Hooks on 01 Jun, 2010 10:40 PM

   

   This is where inheritance breaks. Oh to have Scala's Traits.

   ModuleContext is the more complex of the two. Essentially you just need to merge the two. SignalContext is pretty straight forward.

   Totally not a stupid question!

   • Edit

4. 4 Posted by Stray on 01 Jun, 2010 10:43 PM

   

   No - it's fair to assume that it would be harder than that - Robotlegs usually surprises me by being simpler than I'd imagined!

   • Edit

5. 5 Posted by tom on 01 Jun, 2010 11:00 PM

   

   thanks. i'm confused though - did you change the source of ModuleContext in robotlegs-utilities-Modular or adjusted your project's context? in the latter case my commands are not triggered by the mapped signals.

   • Edit

6. 6 Posted by Stray on 01 Jun, 2010 11:04 PM

   

   I changed the source of ModuleContext in the modular utils library itself.

   Ugly but effective.

   It's one reason why I like to have source and not just swc for my libs!

   • Edit

7. Support Staff 7 Posted by Joel Hooks on 01 Jun, 2010 11:15 PM

   

   http://gist.github.com/421669

   Your context would likely look like this.

   I recommend not monkey patching libraries unless it is actually necessary and a new cleaner base isn't an option :>

   • Edit

8. 8 Posted by tom on 01 Jun, 2010 11:38 PM

   

   thanks a lot, compiles fine.

   i guess i have an additional problem:

   commandMap.mapEvent(ContextEvent.STARTUP_COMPLETE, StartupCommand, ContextEvent, true);

   StartupCommand emits a signal which is mapped to a command

   signalCommandMap.mapSignalClass(LoadModuleSignal, LoadModuleCommand);

   LoadModuleCommand is not getting executed. maybe it's too early to do so - the main class' applicationComplete event is triggered after the StartupCommand has been executed.

   • Edit

9. Support Staff 9 Posted by Joel Hooks on 01 Jun, 2010 11:48 PM

   

   so, mapping the signal returns the signal instance. Are you using that?

   var signal:LoadModuleSignal = signalCommandMap.mapSignalClass(LoadModuleSignal,
         LoadModuleCommand) as LoadModuleSignal;
   
   signal.dispatch();
   

   • Edit

10. 10 Posted by tom on 02 Jun, 2010 12:16 AM

    

    great, it's working. did i fail to read the documentation? doh. anyway, thank you very much.

    err - now i've run into another problem.

    Error: Injector is missing a rule to handle injection into target [object ModuleReadyCommand]. Target dependency: org.robotlegs.utilities.modular.core::IModule

    ModuleReadyCommand is mapped to ModuleReadySignal

        signalCommandMap.mapSignalClass(ModuleReadySignal, ModuleReadyCommand);
    

    the signal's constructor calls super
    

        super(IModule);
    

    finally, the command requests injection

        [Inject]
        public var module : IModule;
    

    reminds me of the ArrayCollection issue but i guess i'm doing something wrong, again.

    • Edit

11. 11 Posted by tom on 02 Jun, 2010 02:26 PM

    

    this issue keeps bothering me. shall i open a seperate post?

    • Edit

12. 12 Posted by Maciek on 02 Jun, 2010 07:31 PM

    

    Tom,

    I kept running into similar issues a couple of weeks ago. Looking at Modular RL, most of the code seemed around sharing dispatchers between modules. Since we're using Signals exclusively for application-level communication, I ignored all that and rolled a simple modular context. I think this is a (considerably) different approach, but it works for me so far. As far as I can tell from looking at Modular RL source, I don't think I'm missing any non-Event-related functionality.

    I found a RL bug in the process and wrote a simple example app to try to hunt it down. The app includes my modular context. It also allows for distinct configuration state for each module instance, something that I needed in my actual app.

    Note that my app doesn't use real Flex modules (just modular pieces of the application), but I think it can be extended to use Flex modules without changes to the context.

    • Edit

13. 13 Posted by Nikos on 31 Jan, 2011 10:41 AM

    

    Awesome code Joel :)

    • Edit

14. Stray closed this discussion on 13 Feb, 2011 04:48 PM.