There are many topics on this subject a quick search will turn
up a number of results, something else you may also be interested
in called LazyMediator utility. This requires swapping out the
default MediatorMap for the lazy map, and adding a "trigger" to the
constructors of your view components. Instead of inspecting every
single display object that lands on stage, the view components
themselves explicitly request mediation. More info: http://wiki.github.com/eidiot/robotlegs-utilities-LazyMediator/
I have that exact example you gave in my e-learning application. Generally the views are mediated in relatively large chunks, but my play / pause toggle and the next / back buttons are mediated individually - even though they're inside another 'lesson controls' view also being mediated.
As Jason says, you can mediate manually, but generally I think mediating things that aren't on the display list is a 'stop and think' moment. If they're invisible then they can't trigger events, so presumably they're listening for events that might indicate that they should be being added? The view-mediator pair should be listening for view-related events... so if the view isn't active, why does it care about anything except an event that should make it active?
It might be worth considering listening for those events outside - in a parent view, or perhaps wiring the event to a command - and then adding the view when it's needed, at which point it will be mediated automagically. You can tell it to update things that might have changed at that point if it needs to.
I'd be slightly wary of adding the view but using visible=false in any but the most trivial of uses (I do use that for internal button states but I wouldn't use it for a whole button). Anything on the display list is eating resources...
But - I'm sure there are corner cases where mediating invisible views is the right solution... maybe you have one of those?
Support Staff4 Posted by Shaun Smith on 02 Apr, 2010 11:41 AM
The display-list-driven, automatic mediation feature is just a
convenience. Most of the time, a user interface component will only
need to be updated (by the application) or receive input (from the
user) when it is on-screen. That said, you have a number of
options. When mapping, the last two parameters of mapView()
indicate how you'd like auto-mediation to be configured. After
mapping, as Jason pointed out, you can manually create and remove
mediators, regardless of the auto-mediation configuration:
As Stray mentioned, the granularity of mediation is up to you.
Perhaps the video player is a completely self-contained component
that dispatches a number of appropriate events. In that case you
might choose to have a single mediator for the component.
In general, I'd avoid using an application framework to wire
together the internals of a component; instead I'd make the
component as self contained and portable as possible, and only use
the framework to wire that entire component back into my