Home → Robotlegs 1 →

Any other way to create mediators other than listening to ADDED_TO_STAGE?

Admin Functions

• Remove

tacklemcclean

02 Apr, 2010 09:14 AM

I've just started looking at Robot Legs, and one thing that sticks out like a sore thumb for me is how you tie view classes and mediator classes with the intent of having the mediator auto-created upon the ADDED_TO_STAGE event firing in the view.

What about the cases where you want to work with views that are not on the stage? Or is the philosophy that you can always set visible = false on the view object?

Are the mediators removed upon REMOVED_FROM_STAGE as well?

Many questions in this post, I know, but here goes another one:
Let's say you have a video player component in a campaign site. This has its associated mediator. What about the play/stop/pause buttons, does it make sense to give them their own mediators, and if so, how is that managed?

1. 2 Posted by Jason Dias on 02 Apr, 2010 09:35 AM

   

   If you want to manually create a mediator do the following,

   mediatorMap.createMediator(yourView);

   http://wiki.github.com/robotlegs/robotlegs-framework/best-practices...

   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/

   Admin Functions

   • Split
   • Remove

2. 3 Posted by Stray on 02 Apr, 2010 10:18 AM

   

   Hi Karl,

   you can mediate at any granularity you like.

   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?

   Plenty to think about!

   Stray

   Admin Functions

   • Split
   • Remove

3. Support Staff 4 Posted by Shaun Smith on 02 Apr, 2010 11:41 AM

   

   Hi Karl,

   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:

   mediatorMap.createMediator( yourView );
   mediatorMap.removeMediatorByView( yourView );
   // OR:
   var mediator:IMediator = mediatorMap.createMediator( yourView );
   mediatorMap.removeMediator( mediator );
   

   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 application.

   Admin Functions

   • Remove

4. Stray closed this discussion on 13 Feb, 2011 07:09 PM.

Comments are currently closed for this discussion. You can start a new one.