tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/84-tab-navigator-deferred-instantiation-issueRobotlegs: Discussion 2018-10-18T16:35:11Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/15895182010-05-03T15:35:29Z2010-05-03T15:38:07Ztab navigator deferred instantiation issue<div><p>I may have just answered my own question, it seems like when
dealing with a view that was deferred, the mediator maps the
listeners correctly when you override the preRegister event instead
of the onRegister event.</p>
<p>If this is wrong and there is a better method or best practice I
am ignoring, please let me know.</p></div>Joeltag:robotlegs.tenderapp.com,2009-10-18:Comment/15895182010-05-03T18:29:44Z2010-05-03T18:29:44Ztab navigator deferred instantiation issue<div><p>Hi Joel,</p>
<p>When a MediatorMap creates and registers a Mediator it calls
preRegister - it then becomes the mediator's responsibility to call
the onRegister hook on itself when it has decided that the view
component is ready:</p>
<p><a href=
"http://github.com/robotlegs/robotlegs-framework/blob/v1.0.3/src/org/robotlegs/base/MediatorBase.as#L58">
http://github.com/robotlegs/robotlegs-framework/blob/v1.0.3/src/org...</a></p>
<p>In the case of Flex components, onRegister is only called after
CREATION_COMPLETE has fired. This design is intended to ease
deferred instantiation issues - you can be sure that your view
component is actually ready before you manipulate it through the
mediator.</p>
<p>In your case it seems that you need access to the view
components before they are actually ready, in which case,
overriding preRegister is an acceptable work-around (but be sure to
call super.preRegister), though it does lead me to question your
current design.. do you really need to have access to those view
components immediately? Robotlegs is designed to be lazy: the code
you put in onRegister for a particular NavigatorContent only runs
when the user actually navigates to that content.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/15895182010-05-04T13:09:58Z2010-05-04T13:10:00Ztab navigator deferred instantiation issue<div><p>Thanks Shaun, that's a great explanation of the sequence of
events that happens for deferred instantiation components.<br></p>
<p>On the current design, I'm not attempting to really access those
views prior to creation, I typically have been putting event
listeners into the mediators to listen for events from the view and
let them get dispatched by the eventDispatcher from the mediator.
This wasn't working properly on those mediators tied to elements in
the tabNavigator.</p>
<p>The issue came to my attention because one of the tabNavigator
tabs has a series of progressive drop down lists, countries,
states, cities, etc to perform a search, so we needed to load the
countries first, then have the events fire down to get states
etc.</p>
<p>good call on the super.preRegister, I'll be sure to add
that.</p>
<p>Thanks!</p></div>Joel