Announcement Announcement Module
Collapse
No announcement yet.
Stage component wiring does not happen in some cases Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Stage component wiring does not happen in some cases

    Hi there,

    I'm facing some unexpected behaviours with stage component wiring.

    1. In stage componante instances which are created in the Main Application class by MXML (and are probably created befor the application context file is parsed), properties are *not* injected.
    2. In instances (in this case TuioView) which are created and added to the display list manually after the application context file is parsed, properties are injected as expected. See this example code which is executed after applicationContext's COMPLETE event:

    var container:UIComponent = new UIComponent();
    var tuioView:TuioView = new TuioView();
    addElement(container);
    container.addChild(tuioView);

    Note, that in this example, the container is first added to the Main App, *then* then instance (tuioView) is added. > Injection works fine.

    3. In another case, where instances (in this case TuioView) which are created and added to the display list manually after the application context file is parsed, properties are *not* injected as expected. See this example code which is also executed after applicationContext's COMPLETE event:

    var container:UIComponent = new UIComponent();
    var tuioView:TuioView = new TuioView();
    container.addChild(tuioView);
    addElement(container);

    Note, that in this example, the nstance is first added to the container, *then* the container is added to the Main App. > Injection does not happen.

    I use no autowiring, lookupByType==true in my defaultObjectDefinitionResolver (actually Spring's DefaultObjectDefinitionResolver):

    <object
    class="com.superfund.components.TuioView"
    singleton="false">
    <property name="tuioModel"
    ref="tuioModel"/>
    </object>

    Am I missing something? I'd expect the props to be injected into tuioObject in all three scenarios.

    Cheers,
    David

  • #2
    logical but not intuitive

    Hi,

    I think the situation you describe is logical if you know the internals of stage wiring, but i understand it's not intuitive.

    Stage wiring happens if an item is added to the stage. In that case an event Event.ADDED is dispatched which is handled by the autoWireStageProcessor (or some similar name). The event that is dispatched is a bubbling event and after some bubbling it will reach the root of your app where the event is processed and the autowiring takes place.

    Now if you add a subcomponent to another component that is not attached to the stage yet this bubbling to the root doesn't take place because the host component is not attached to the stage yet. If you add that host component (your second situation) afterwards to the stage only the Event.ADDED from that host component is fired and bubbles to the root. But the event of its child is already dispatched when it was added to the host component and will never reach the autowire processor.

    Hope that is clear,

    NB for the SAS developers. Is there a specific reason that you guys use Event.ADDED instead of Event.ADDED_TO_STAGE? I think if you use the latter things might work in the second situation like described in the previous post. Not sure but seems reasonable....

    Arnoud

    Comment


    • #3
      Yeah, I'd also vote for ADDED_TO_STAGE.
      ADDED_TO_STAGE does not work for very early FP9 Versions. Maybe this was the reason, but personally I would not mind.

      However, I'd expect for case 1 to work, since the docs say "Spring Actionscript will wait until the container has finished loading and parsing its configuration,
      after which it will loop through the entire current displaylist once to autowire the already created stage components."

      However, maybe here it's the same situation, children being added first and the outermost container being added last -- the latter happening after the parsing of the configuration.

      Hmm ... Any workarounds for getting scenario 1 (MXML) to work?

      David

      Comment

      Working...
      X