Home > Robotlegs > Tuning The Legs

Tuning The Legs

The Robotlegs MVCS implementation was designed to be convenient: quick-n-easy for common use cases. Nothing is free, of course, and that convenience comes at a cost. I want to highlight a few things that can be tweaked to improve performance for applications that really need it.

Automatic Mediation

In order to determine the scope of a view component, Robotlegs listens to the contextView for bubbling capture-phase ADDED_TO_STAGE events:

MediatorMap.as#L233
MediatorMap.as#L260

Every display object that lands on the stage inside the contextView is checked against a mapping dictionary. This can be quite expensive for complex display object hierarchies where there is a lot of re-parenting. It’s also the only option available if you want to keep your view components completely framework-unaware. If, however, you’re prepared to modify your components slightly (it’s a one-liner) then you can try out this utility:

http://github.com/eidiot/robotlegs-utilities-LazyMediator

Instead of listening for ADDED_TO_STAGE events emitted by every component, we listen only for custom events dispatched by view components that explicitly require mediation.

Note: This utility currently only supports the MediatorMap and needs to be expanded to support the ViewMap. Fork and improve!

Default Injection Points

The actors in the MVCS package have a number of pre-configured injection points (dependencies). When you extend mvcs.Command all you are really doing is inheriting some dependencies:

mvcs/Command.as#L23

Whilst handy, it is quite seldom that we actually use all of those in a given Command.

A much cleaner, and ever-so-slightly cheaper approach is to declare only the dependencies that you actually need. Instead of extending Actor or Command (this doesn’t work so well for the Mediator class), just create a vanilla class and declare your dependencies manually:

public class MyCommand
{
	[Inject]
	public var injector:IInjector;

	public function execute():void
	{
		injector.mapClass( Vehicle, Car );
	}
}

Remember, the Robotlegs apparatus is already mapped for you if you need anything:

mvcs/Context.as#L190

Notice that the IEventMap is not mapped as a value or singleton – you’ll get a new IEventMap instance whenever you ask for one.

That’s it for now!

Categories: Robotlegs Tags: , , ,
  • codecraig

    I used the “Default Injection Points” approach in a project that was using/creating non-ui flex modules. I have my own Command class that just injects the ICommandMap, IEventDispatcher and IInjector (it exludes the mediator).

    I've also done a similar thing for Context since I don't have a “contextView” or mediators. Glad to see I wasn't totally off in my own world :)

  • http://flexdiary.blogspot.com Amy Blankenship

    Can you clarify how you listen for ADDED_TO_STAGE, which doesn't bubble? Do you add a listener when the ADDED event is fired?

  • http://shaun.boyblack.co.za/blog/ shaun

    Hi Amy,

    ADDED_TO_STAGE events from children can be caught in the capture phase:

    http://github.com/robotlegs/robotlegs-framework...

    It's a little deceptive as it's the only instance I know of where there's a capture phase without a bubbling phase.

  • sas

    Hi, does the LazyMediator work with RobotLegs v1.1? And if not, why not update it ot make it compatible?

blog comments powered by Disqus