tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/8394-preattached-child-view-of-mediated-parent-not-triggering-mediationRobotlegs: Discussion 2013-12-23T09:26:42Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/302422652013-11-28T01:17:48Z2013-11-28T01:17:49Zpreattached child view of mediated parent not triggering mediation<div><p>I created a workaround for the issue by deferring attachment of
the child object until the parent fires off added to stage. There
might be slight momentary visual glitch doing it this way, but
that's code in my domain that I can address.</p>
<p>This issue still irks me as I feel it will come up later. It
makes me wonder what best practices are for automatic mediator
invocation..</p></div>armoredblimptag:robotlegs.tenderapp.com,2009-10-18:Comment/302422652013-11-28T16:55:33Z2013-11-28T17:02:15Zpreattached child view of mediated parent not triggering mediation<div><p>Hello,</p>
<p>I end up answering questions about Starling, but, the problem
is, I have much less experience with Starling than the people
asking the questions :P<br>
Soo, should I put some time into learning Starling? - question for
myself.</p>
<p>Are you using one of the available Starling extensions for
robotlegs? If the answer is yes, which one?</p>
<p>From what I understand while looking at some examples using a
Starling extension for robotlegs, the flow should be like this:</p>
<ul>
<li>in the Main class extending a regular Sprite add an event
listener for ADDED_TO_STAGE</li>
<li>
<p>in the handler of ADDED_TO_STAGE:</p>
<ul>
<li>create a Starling instance with a <strong>Starling root
class</strong> and a stage and add a Starling event listener for
CONTEXT3D_CREATE</li>
<li>create and configure a robotlegs context, which expects a
<strong>non-Starling DisplayObjectContainer</strong> as the context
view ( the Main class extending flash.display.Sprite)</li>
</ul>
</li>
<li>
<p>in the handler of CONTEXT3D_CREATE add the Starling views to the
Starling stage of the Starling root class</p>
</li>
</ul>
<p>Could it be that you added the ChildView to the stage before
Starling was initialized, or before the robotlegs context has
finished the configuration?<br>
Or, maybe you added ChildView to the ParentView in ParentView's
constructor? The stage is null in the constructor.</p>
<blockquote>
<p>However, if I later remove the child view, dispose of it, then
create a new child and add it the child mediator is automatically
initialized as expected.</p>
</blockquote>
<p>Because at a later point in time the stage was available?</p>
<blockquote>
<p>I created a workaround for the issue by deferring attachment of
the child object until the parent fires off added to stage.</p>
</blockquote>
<p>That's the right thing to do, in my opinion.</p>
<blockquote>
<p>It makes me wonder what best practices are for automatic
mediator invocation..</p>
</blockquote>
<p>You provide robotlegs with a DisplayObjectContainer as a
contextView when you create a robotlegs context.<br>
Behind the scenes the framework is adding event listeners for
(**the flash**) Event.ADDED_TO_STAGE for the root container and for
each container that is added to the root stage.<br>
These are the classes and extension responsible for that:</p>
<p>StageObserver, ViewManager, ManualStageObserver,
StageCrawlerExtension..</p>
<p>ViewManager<br>
In Robotlegs 2, stage-event listening is centralised to a
ViewManager. The ViewManager listens for views landing on the
stage, and being removed from stage, and informs interested
parties, such as the mediatorMap, accordingly.</p>
<p>ManualStageObserverExtension<br>
This extension install a manual Stage Observer</p>
<p>StageCrawlerExtension<br>
View Handlers (like the MediatorMap) handle views as they land on
stage.<br>
This extension checks for views that might already be on the stage
after context initialization and ensures that those views are
handled</p>
<p>Now, for a mediator to be created automatically there are only a
few conditions to be met:</p>
<ul>
<li>having a contextView</li>
<li>having a Context with the needed extensions installed</li>
<li>having a configuration, i.e. mapping of a view to its mediator
**before"</li>
<li>adding a view to the contextView's stage</li>
</ul>
<p>You are right, the Starling Events are different from the
flahs.event.Event. Also, Starling has its own EventDispatcher, so
the robotlegs shared event dispatcher can't hear the events
dispatched on the Starling one.<br>
The Starling extensions for robotlegs are listening for Starling
events and are managing the automatic mediators creation
internally.</p>
<p>I'd be curious to see how you've initialized Starling, the
rl-Context, how the mappings for your mediators look like, and the
exact order of initialization/creation//addition of views to the
stage. It would help other Starling users in the future( and me
too, to answer their questions;) ), if you pasted the relevant code
in here.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/302422652013-12-02T08:00:06Z2013-12-02T08:00:06Zpreattached child view of mediated parent not triggering mediation<div><p>Starling ViewMap extension doest look for children’s of
display object that is added, so you have to add all your objects
on added to stage if you want to mediate them. Or you can make a
pull request and add that feature :)</p></div>matej