Injection Support without a ContextView

dan's Avatar

dan

26 Jun, 2014 11:41 PM

Hi,
I have an application that has two modules and I'm considering having two separate contexts. One of the modules doesn't require dynamic mediation of views at all, only DI support (performance is important) and after configuration/mappings are created, I'd like to just have injection points satisfied in the constructor. Does that make sense?

My question, is can I setup such a context that few extensions installed? Do I need a contextView?

   [Inject]
   public var someService:ISomeService
   function ClassConstructor
   {
      getStaticInjector.injectInto( this );
   }
  1. Support Staff 1 Posted by Ondina D.F. on 27 Jun, 2014 07:46 AM

    Ondina D.F.'s Avatar

    Hi Dan,

    Yes, you can do that.

    Your custom MVC Bundle could look like this:

    
    public class CustomMVCSBundle implements IBundle
    {
        public function extend(context:IContext):void
        {
            context.install(
            EventDispatcherExtension,
            EventCommandMapExtension,
            LocalEventMapExtension
        );
    }
    

    Your Context:

    
    private var _context:IContext;
    private function createRLContext():void
    {
        _context = new Context();
        _context.install(CustomMVCSBundle);
        _context.configure(ViewLessConfig);
        _context.initialize();
    }
    

    Note the last line: _context.initialize(); You have to initialize your viewless context manually!

    
    
    public class ViewLessConfig implements IConfig
    {
        [Inject]
        public var injector:IInjector;
        
        [Inject]
        public var commandMap:IEventCommandMap;
        
        public function configure():void
        {   
            injector.map(SomeModel).asSingleton();
            commandMap.map(SomeEvent.TRIGGER_SOMETHING)
            .toCommand(SomeCommand);
        }
    }
    

    The only problem with a viewless context is that you can't use the Modularity extension, because, as far as I know, it needs a contextView.

    Does that help answer your question?

    Ondina

  2. 2 Posted by greenLED on 27 Jun, 2014 11:26 AM

    greenLED's Avatar

    Hi Dan. Yes, your modules make sense, at least for me. I am working with
    "faceless" modules too. For example, I have a database access module with
    lots of mappings that are not relevant for the rest of the application.
    Putting this logic inside a module should speed things up, I think.
    Anyway, I have never made a performance test.

    Meil Manuell wrote an excellent article about this modules at
    http://statemachine.org/?p=492. Inspired on it, I made my own
    implementation for RL2. Basically, you need to create a context for the
    module and install+configure whatever you want on it, then add it as a
    child of your current context, and lastly initialize it. You could like to
    save a reference to the created context in case you want to destroy it
    (unload module). In that case, you only need to call it's destroy()
    method, and it will be automatically removed from the main context. Note
    also that you will inherit parent dependencies...cool!

    El Jue, 26 de Junio de 2014, 7:42 pm, dan escribió:

  3. Support Staff 3 Posted by Ondina D.F. on 28 Jun, 2014 12:58 PM

    Ondina D.F.'s Avatar

    @greenLED Thank you for mentioning 2 important things, that where missing in my code example, namely the fact that the main context should add the child context through context.addChild(), and that it should also remove it, when needed!
    My example was based on the one I posted in another discussion (http://knowledge.robotlegs.org/discussions/robotlegs-2/10174-is-the...), but when I changed the names and deleted the lines that were referring to a child context with a contextView, I deleted the context.addChild(childContext);
    as well. Sorry about that.

    
    private var _parentContext:IContext;
    
    private var _childContext:IContext;
    
    private function createChildContext():void
    {
        _childContext = new Context();
        _childContext.install(CustomMVCSBundle);
        _childContext.configure(ChildContextConfig);
    //
        _parentContext.addChild(_context)
        _childContext.initialize();
    }
    ....
    
    private function destroyChildContext():void
    {
        _parentContext.removeChild(_childContext);
        _childContext.destroy();
    }
    

    Neil's solution looks nice. I haven't seen it until now. Thanks for the link.

  4. 4 Posted by dan on 28 Jun, 2014 01:47 PM

    dan's Avatar

    Is it necessary for the contexts to have a parent child relationship? I
    actually don't want them to have anything to do with one another. I also
    don't have control over which context will be initialized first!

  5. Support Staff 5 Posted by Ondina D.F. on 28 Jun, 2014 04:25 PM

    Ondina D.F.'s Avatar

    I actually don't want them to have anything to do with one another.

    In this case the code from my first post would suffice. And, when/if you needed to destroy it, you'd use context.destroy().

  6. 6 Posted by greenLED on 28 Jun, 2014 09:31 PM

    greenLED's Avatar

    Are you meaning a context chain like

    mainContext {modA {modB {modC {...}}}}

    It is not necessary. Just add them as childs of your main context, like

    mainContext {modA{}, modB{}, modC {}, ...}

    This way, the main context knows how to create/destroy each module. Of
    course, you could have modules inside modules using this same mechanism, I
    think (never tried).

    El Sab, 28 de Junio de 2014, 9:47 am, dan escribió:

  7. 7 Posted by dan on 29 Jun, 2014 08:22 PM

    dan's Avatar

    Awesome thanks. Thanks for the preview I'll try this out asap.

  8. 8 Posted by greenLED on 30 Jun, 2014 12:41 AM

    greenLED's Avatar

    You're welcome. Good luck.

    El Dom, 29 de Junio de 2014, 4:22 pm, dan escribió:

  9. Ondina D.F. closed this discussion on 25 Jul, 2014 09:15 AM.

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