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!

A huge big “Thank You” to everyone involved. Let the “utility building” begin!

Robotlegs is an automated dependency injection framework for Flash, Flex and AIR.

The (better, but not awesome) code is over at:

http://github.com/darscan/SillyStockPriceExample/tree/robotlegs

I’m still trying to figure about the best way to illustrate the simplicity and flexibility of the Robotlegs framework. In the meantime however, I thought I’d respond to this cool Swiz video by doing the same thing with Robotlegs – except ending up with a modular (as opposed to a static) app, and throwing in some git/GitHub love as a bonus.

I don’t have a nice mic, so I strapped a phone to the side of my head and left myself a really long voicemail. Anyhoo:

You can grab the (terrible) source over at:

http://github.com/darscan/SillyStockPriceExample

RobotLegs is nearly at v1.0! Many awesome changes since v0.8, with the most community involvement to date:

http://github.com/robotlegs/robotlegs-framework/commits/v0.9.2

The “Official RobotLegs Framework Repository” has also been moved:

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

A LOT of exciting stuff is going on, and I encourage you to check out the Wiki:

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

An upgrade guide from v0.8 isn’t really necessary is it? Here’s a list of some of the changes introduced in this last sprint:

• SwiftSuspenders DI solution fully integrated (bundled) into RobotLegs
• Constructor Injection (via SwiftSuspenders)
• Bonus DI Adapters removed
• CommandMap now features strong Event mapping
• As3commons logger removed
• Utils inlined and removed: createDelegate() and DelayedFunctionQueue
• dispatch() helper method renamed to dispatchEvent()

And various miscellaneous optimisations, cleanups and API changes.

RobotLegs AS3 is a Dependency Injection Driven MVCS Framework for Flash, Flex and AIR.

Help make RobotLegs the cleanest, smallest, most testable, and most kick-ass framework for Flash and Flex ever built – join the discussion group:

http://groups.google.com/group/robotlegs/topics

Or help fill up the Robotlegs Knowledgebase:

http://knowledge.robotlegs.org/

The RobotLegs Library has received it’s first community contribution! Till Schneidereit fixed something that had been bugging me for a while: the existence of the FlexMediator. Initially I split this out to avoid compiling any Flex classes into pure AS3 projects. Till submitted a patch that allows the Mediator to detect the presence of Flex without this side-effect.

This is why I love Git (and GitHub). Anyone can come along, fork the project, make changes to it, and send a Pull Request – without requiring any permission to do so. This significantly lowers the barrier-to-entry for once-off or “impulse” contributions.

Anyhoo, this change to the Library requires a find-n-replace on old application code:

FlexMediator -> Mediator

RobotLegs AS3 is a Dependency Injection Driven MVCS Framework for Flash and Flex.

• RobotLegs is an Architectural (or Structural) Action Script 3 Framework.
• It provides a mechanism for wiring objects together.
• It promotes a usage pattern for keeping your code loosely coupled and easy to test.
• It has a narrow scope: wiring.

How?

RobotLegs relies on two things fairly unique to the Flash Platform: A powerful, built-in, standardised Event Model, and a Display List that is 100% integrated with that Event Model.

Why?

Using these two things (and any compliant Dependency Injection framework) RobotLegs is able to offer a minimally invasive solution for wrapping an application around a display object hierarchy – even if you don’t have access to modify the Classes within that hierarchy. Depending on your style, this may be hugely advantageous.

But What About The Lolrus?

Swiz, Parsley, Mate, PureMVC, HydraMVC and Cairngorm exist to solve the same basic problem, but they suffer from blurry scopes and/or poor implementations.(*) Here are some initial thoughts on that: http://shaun.boyblack.co.za/blog/2009/04/29/another-architectural-framework-but-why/

Some may defend their violations, claiming pragmatism over purism – that is dangerous: the library that you use to wire your application together directly affects the flexibility and, more importantly, testability of your code. I am being pragmatic: if my Classes are hard to test (Singletons, Statics) then my application will be fragile and I won’t be free to refactor with speed and confidence. If code can’t be refactored easily it is dead. If I can’t refactor my code easily my progress as a developer slows down drastically.

So, Is RobotLegs Perfect?

Well no, but it does everything that it’s advertised to do, and tests are being set up to ensure that it stays that way. A framework must pick it’s battles carefully. There are one or two things that need some very careful consideration before RobotLegs can reach 1.0

Also, some peer review would be nice. I’m a mediocre programmer at best. I’m on that part of the curve where I’m knowledgeable enough to know exactly how bad I am.

Where Is The Website? OMG, Where Are The Docs?

I thought it would be best to determine whether or not I have completely missed the point before investing time and energy into support artifacts.

Dude, You’re Wearing Sunglasses Indoors. WTF?

So, have I missed the point? Do you really think that ANY of the architectural frameworks out there are good enough?

(*) Actually, it’s not really that, it’s more about how your application code looks when written on top of these frameworks.

http://github.com/darscan/robotlegstests

Feel free to fork if testing is your idea of insane weekend fun!

RobotLegs AS3 v0.7 (codename ShortWave) is up on GitHub:

This massive update to the RobotLegs framework adds a dispatch() helper method to the mvcs context.. That is all!