[Inject] in Views - How to and whether to?

stevensacks's Avatar


13 Dec, 2009 09:47 PM


I have noticed that the [Inject] metadata does not work in a class that doesn't extend Actor or isn't mapped as a singleton or class in a context. One such example is view classes that are not mapped as singletons, but might need access to a singleton that was mapped by the context.

injector.injectInto() only works with instances, but I would want every instance of MyView to have access to an injected singleton.

Because of the way it currently works, I inject the singleton into the mediator of the view, and via events dispatched from the view to the mediator, I access the singleton.

So, the question is whether or not it is a bad practice to pass injected singletons into views and better to let their mediators keep those references, or, if that's an acceptable architecture, how do you make [Inject] work in those views?

Steven Sacks

  1. Support Staff 1 Posted by Shaun Smith on 13 Dec, 2009 09:54 PM

    Shaun Smith's Avatar

    Hi Steven,

    The [Inject] metadata has little to do with Actor (or Robotlegs in fact). It has everything to do with objects that are managed by a Dependency Injection container (SwiftSuspenders by default) - which relates to "mapped as a singleton or class in a context" as you mentioned. The DI library has to have a rule for the dependency, and it has to be told to inject into your target class (the injectee). Robotlegs does all of this for you when it comes to Mediators and Commands.

    The purpose of the Mediator is to remove all application specific knowledge from a view component. But what I would do in your case is expose a method on the view component that accepts some kind of reference (the dependency), set up the dependency for injection on your mediator, and pass that reference through to the view in the mediator's onRegister hook. Which I think is what you are doing already.

    If you're not using Mediators, then you could use the ViewMap to handle injection directly into view components as they arrive on stage. For example, inside MyComponent:

    public var myDependency:SomeDependency;

    In your context, or in a command:

    // .. //

    and then, later:

    addChild(new MyComponent());

    You could use both the MediatorMap and the ViewMap, but that seems like overkill to me - and has performance tradeoffs.

  2. 2 Posted by stevensacks on 13 Dec, 2009 10:03 PM

    stevensacks's Avatar

    The purpose of the Mediator is to remove all application specific knowledge from a view component.

    This pretty much answered the question that I shouldn't do it. The rest of the information is good to know, as well.


  3. Support Staff 3 Posted by Shaun Smith on 13 Dec, 2009 10:29 PM

    Shaun Smith's Avatar

    Hah, I suppose the answer should have been: If you are using the Mediator pattern then it is not appropriate to give application-scope instances to your view components.

    But that's only if you use the Mediator pattern. Some developers prefer the Presenter pattern - which roughly boils down to injecting Presenters directly into your view components - or variations thereof.

  4. Till Schneidereit closed this discussion on 15 Dec, 2009 06:36 PM.

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