Child Injector Mapping not stored? about swiftsuspenders HOT 7 OPEN

That does look like a bug indeed. I'll have a look.

from swiftsuspenders.

In this example, what class is the InfoGraphicsDataModel.rawContent property? Is that class mapped to anything in the injector?

Also, Does the class for the InfoGraphicsDataModel.rawContent property contain any injection points ( [Inject] tags) of its own? If so, what are they? I'm particularly interested in possible circular class injection pathways (i.e. if the rawContent class also had an [Inject] tag on a property of type InfoGraphicsDataModel.)

from swiftsuspenders.

No, it is just a loaded swf. It's document root as dependencies marked with

[inject]

That need to be fulfilled that’s why I am injecting into it. I am creating a child injector because I am loading several different swfs that need different values injected. So in the for loop I create a child injector for each one, map the 1 dependency that is unique per loop then inject it into the loaded swf.

-----Original Message-----
From: ZackPierce [mailto:[email protected]]
Sent: Sunday, June 19, 2011 5:57 PM
To: [email protected]
Subject: Re: [SwiftSuspenders] Child Injector Mapping not stored? (#54)

In this example, what class is the InfoGraphicsDataModel.rawContent property? Is that class mapped to anything in the injector?

Reply to this email directly or view it on GitHub:
#54 (comment)

from swiftsuspenders.

Thanks for the clarification.

from swiftsuspenders.

Alright, I think I'm still not comprehending the full class layout here. In particular, at what point in the object lifecycle is the rawContent property being set. Let's try to winnow it down to the simplest set of classes and calls that will break.

Also, please pardon my pedantry, but I want to point out that injectInto fullfills all the injection requirements of the object passed. I'm worried that you may be using injectInto as if it were meant to accomplish property-assignment:

// *not* what happens after injectInto(vo.rawContent)
vo.rawContent = someObjectFromTheInjector;

when in fact, the SwiftSuspenders code is trying to do:

 // roughly what happens when injectInto(vo.rawContent) is called
vo.rawContent.propertyA = somethingElseFromTheInjector;
vo.rawContent.propertyB = yetAnotherOtherThing;

With that clear, how does this sound for a class hierarchy and corresponding test?
Frame ~= InfoGraphicsDataModel
Door ~= the class of InfoGraphicsDataModel.rawContent
Knob ~= some sub-property of InfoGraphicsDataModel.rawContent that needs to be injected

class Frame {
    public var door:Door = new Door()
}

class Door {
    [Inject]
    public var knob:Knob;
}

class Knob {
}


// In the appropriate unit test class
[Test]
public function childInjectorCorrectlyHandlesSubPropertyInstantiation():void {
    var injector:Injector = new Injector();
    injector.mapClass(Knob, Knob);

    var childInjector:Injector = injector.createChildInjector(injector.getApplicationDomain());
    var frame:Frame = new Frame();

    childInjector.mapValue(Frame, frame);
    childInjector.injectInto(frame.door);
    Assert.assertNotNull(frame.door.knob);
}

Since that above unit test passes in the current SwiftSuspenders codebase, either I have missed some aspect of the class relationships described, or there is some other misunderstanding (or bug) going on. If it's the former, please suggest modifications to the above minimal test and class-set.

from swiftsuspenders.

Zack,

I am using injectInto to fulfill the injection dependencies in the instance of rawContent passed. The swf loaded and referenced as rawContent is not mapped in the injector, it just has dependencies that need to be fulfilled. I did this so I could allow the developers of all the modules access to parts of the framework I am building automatically.

So rawContent is being set after it is loaded by the loader. So when I encounter the bug rawContent is already loaded and the constructor would have been called since its a loaded swf.

I am looking at your example below, I think your basic class structure is ok, but what I am doing with the injector is different.

• Door is loaded via a loader, not instantiated (so technically its in a child application domain), each Door is a separate swf that all extend a common base class
• I don't map Frame by value in the parent injector
• I don't map knob by class in the parent injector
• each Door is stored in a separate instance of Frame
• in my example each Door needs a unique Knob value, so for each Door I create a child injector and map a unique value for Knob via mapValue (). I do this so that I can put the ([Inject] public var knob:Knob ) declaration in the base class that all the loaded Door's must extend for their document class. If I didn't do this I would have to have each developer use a named injection on their doc class which would make initial testing harder. I then use these child injectors on each unique instance of via injectInto. Essentially I am trying to use the child injectors to store dependencies that require unique values but implement the same class.

I based this idea on the following lines from the documentation.

"The child injectors forward all injection requests they don’t have a mapping for to their parent injector. This enables sharing additional rules between the injectors"

"If a mapping from a parent (or other ancestor) injector is used, that doesn’t mean that the child injector isn’t used for subsequent injections anymore. I.e., you can have “holes” in your child injector’s mappings that get filled by an ancestor injector and still define other mappings in your child injector that you want to have applied later on in the object tree that is constructed through DI."

from swiftsuspenders.

If I create the childInjector using the application domain of the loaded swf instead of the main application domain the error disappears and I don't have to make that second request to get the dependency to map correctly.

Replaced

var childInjector : IInjector = injector.createChild( injector.applicationDomain )

with

var childInjector : IInjector = injector.createChild( (DisplayObject (vo.rawContent).loaderInfo.applicationDomain ));

it must have something to do with the injecting into loaded swfs.

from swiftsuspenders.