Injecting into views, alternative to .injector?

lukevanin's Avatar


12 Oct, 2011 02:44 PM

I am maintaining an AIR application which was originally built using FlashDeevelop and Flex SDK 4.1 (or earlier) and prior versions of RobotLegs and SwiftSuspenders. The libraries were kept separately from the application code and have since been lost and so I do not know for certain which version the application used.

Since taking the project on I have moved it into Flash Builder 4.5.1 using Flex SDK, AIR, RobotLegs 1.5.1, and SwiftSuspenders 1.6.0.

At one point RL and/or SS has changed since the current version does not behave as expected by the application. The problem seems to be related to using the [Inject] meta-tag inside a view (views are .mxml files). Eg:

[Bindable][Inject (name="stateVO")]     public var stateVO:StateVO;
[Bindable][Inject (name="detailsVO")]   public var detailsVO:DetailsVO;
[Bindable][Inject] public var assetModel:AssetModel;                
[Inject] public var contextView:DisplayObjectContainer;

The view then accesses these variables after the creationComplete() event has fired. This seems to have worked with at least one prior version of RobotLegs, however the current version does not seem to follow this behaviour. I added a method with [PostConstruct] meta-tag to the view, but the method is never being called. This leads me to believe that injection is not being applied to the view. The injector does work on the mediator at least.

The documentation does not specifically mention any changes in this regard (or if it does I must have missed it). In searching the forum the only relevant posts I came across mentioned using the ".injector" property on the mediator, however this no longer seems to be applicable:

So my question is, what is currently the recommended best practice for injecting objects into views, and can I retro-fit it to the existing application?

  1. Support Staff 1 Posted by Till Schneidere... on 12 Oct, 2011 02:51 PM

    Till Schneidereit's Avatar

    The situation I'm currently picturing - and I quite like what I see - is your post being about as long as it is, maybe even (a lot) longer, but with the censored expletives being omitted in favor of links to actual, you know, outdated posts.

    Meaning: It would help a lot if you could point out a misleading post or two for us to delete or update.

  2. Support Staff 2 Posted by Stray on 12 Oct, 2011 03:00 PM

    Stray's Avatar

    Hi Luke,

    not everybody can work with the latest-greatest version of the codebase. For example, my team are stuck with 1.0 because we have an Air shell which is installed on user's machines by admin. (yes, with hindsight I wish I'd done it differently).

    So - while they're of no use to you, that doesn't make they're of no use to anyone.

    But also - RL is using semantic versioning, so the only occasion where you should get stung by this kind of thing is where there was a bug and we've fixed it.

    For example: in early versions of RL 1 it was possible to use injections that were made for the mediatorMap's use to get views and mediators to be injected elsewhere, but that's a really unstable approach because there can be many views with the same class (and corresponding mediators) and there's no way of knowing which instance got injected. So we've cleaned it up.

    So - if you have a specific post that has sent you on a goose chase, please let us know what it is and we'll add a comment to save future people from getting stung by it.

    The pragmatic answer of course is that none of us get paid for this work, simply maintaining the forum day-to-day takes a lot of effort and working backward through thousands of posts to find the handful that may cause a problem is not something I can imagine any of us have time to do. But if you'd like to volunteer to do it then let us know.

    And +1 for what Till said. Only I'd probably also wrangle for some sort of gracious nod to the fact that the forum is, in comparison to most open source forums, a super fast, helpful and useful resource if you simply ask a new question.

    Perhaps you forgot to set the -polite='true' parameter on your language compiler before you posted? I'd have preferred that argument to the Tarantino nonsense.


  3. 3 Posted by lukevanin on 12 Oct, 2011 03:28 PM

    lukevanin's Avatar

    @till and @stray I have amended my post as per your suggestions. I apologise for my original crassness.

  4. 4 Posted by Stray on 12 Oct, 2011 03:39 PM

    Stray's Avatar

    That's cool - thanks :)

  5. Support Staff 5 Posted by Shaun Smith on 12 Oct, 2011 04:17 PM

    Shaun Smith's Avatar

    Have a look at the changelog:

    If you scroll down to v1.1.0, you'll notice this:

    Updated SwiftSuspenders to v1.5.1
    PLEASE NOTE: mapValue no longer injects into the value instance – the old behaviour was incorrect.

    My guess is that you were using a version prior to v1.1.0.

    To fix this you can do the following:

    1. Inject the injector into your mediator:

    [Inject] public var injector:IInjector;

    1. Inject into the view inside the mediator's onRegister (or preRegister if you need it sooner):
    override public function onRegister():void {
      // ....

    By the way, the first link you posted contains a description of both the problem and the solution:

  6. 6 Posted by lukevanin on 13 Oct, 2011 07:36 AM

    lukevanin's Avatar

    Thank you, that mostly works. The missing piece, it seems, is that it is of critical importance to use a [PostConstruct] to access the injected values. It makes sense in hindsight, but it's not a very obvious approach. Perhaps this could be mentioned in "Common problems" page?

  7. Support Staff 7 Posted by Shaun Smith on 13 Oct, 2011 01:37 PM

    Shaun Smith's Avatar

    Hmm.. it is mentioned in the Common Problems page:

  8. 8 Posted by lukevanin on 14 Oct, 2011 07:54 AM

    lukevanin's Avatar

    Yes I did see that, I meant combine the bits of information into one coherent description. Look I'm not trying to be difficult, and I do appreciate what you're doing here. I'm just saying it would make sense to have the information in a single place rather than having to assemble it from: a forum post, somewhere in the middle of a version change list, and another page, just to help out those of us who aren't RL aficionados.

  9. 9 Posted by Stray on 14 Oct, 2011 09:24 AM

    Stray's Avatar

    Anything that comes up regularly is in the Common Problems wiki, and probably also covered in the Robotlegs book.

    Your problem doesn't come up regularly (we always advised against mixing mediators with view injection and not many people went against that). I appreciate that you've inherited the problem, but can you imagine how difficult it would be for us to write consolidated debug guides for every possible corner case problem that emerges as a result of misuse of the framework?

    Purely to cover the strange accident of someone not knowing which version of the library their project was built against?

    (You could probably decompile a swf and find that out by the way, if you have one).

    That's why we're so keen on the forum - people can ask their specific problem, in terms that they understand, and we can help them diagnose it.

    I'm sorry you found it difficult to find the information, but to be fair, if your first post had been a straight question (as you've edited to) instead of a general sarcastic poke then you'd have had your answers an hour quicker. Possibly within 10 minutes of posting. As it was, Shaun still answered you within 2 hours of posting.

    So - I'd work on your own usage of forums first, as that's within your control - and that was the biggest bottleneck in getting your answer.

    Given that your response was still to be critical rather than just say thanks, or ask whether there's a reason why we haven't done what you wanted, or - and yes, some people really do do this - offer to WRITE the blog post or forum / wiki entry that clearly captures the problem and solution you experienced... it seems like the whole 'how I use the forum affects the responses I get' message from the first post didn't really stick.

  10. Ondina D.F. closed this discussion on 21 Nov, 2011 09:11 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