Joel Hooks It is not enough for code to work. Code that works is often badly broken

Robotlegs Image Gallery Example using AS3-Signals and the Presentation Model

Jason Crist posted a thought provoking request for his upcoming presentation comparing Robotlegs and Swiz. He’s got a clever knack for stirring the framework ant pile and getting developers eyes off their IDEs long enough to discuss their passions. In this case the developers include Ben Clinkinbeard, Shaun Smith, Jesse Warden and myself.

These conversations are always good natured. While we work on (or use) “competing” frameworks there is always a sense of mutual respect. We like our tools but have obvious inclinations towards the projects that we’ve invested our hearts and souls into.

Ben Clinkinbeard has pointed out (several times!) that Robotlegs is all about extending the MVCS classes. My stock answer is that there is a clear separation between the framework and the concrete MVCS implementation. To paraphrase Ben, “Well show it to me then!”

All of the “official” Robotlegs examples are making use of the MVCS implementation. Why? Because it is solid, recognizable, and fairly easy to get one’s head around. It provides a common ground for developers and a set architectural structure which is a huge advantage in any team environment. It is important to make the distinction between the framework and the MVCS implementation. What does that even mean? At the core, Robotlegs is a modular set of tools to provide a convenient mechanism for wiring applications. Robotlegs is not doing class reflection. Robotlegs is not an automated dependency injection solution. Robotlegs is an adapter to a dependency injection solution,by default the lightweight SwiftSuspenders library. Through a set of tools, namely the MediatorMap, CommandMap, ViewMap, and the injection adapter Robotlegs provides a robust starting place to begin coding your application.

The MVCS implementation is a set of base classes loosely modeled on PureMVC. At the heart of the implementation is the Context. The Context creates instances of the various mapping classes, the injection adapter, and gives the developer a centralized IEventDispatcher that can be used for messaging between application tiers.. The other three classes, Actor, Mediator, and Command, reduce boiler plate and provide convenient access to injected dependencies typically used in the the MVCS tiers.

What if you hate PureMVC, don’t want to extend any framework classes, or generally just want to work in a different way outside of a prescribed MVCS architecture?

No problem.

Here’s the deal. Robotlegs, the framework, is a set of interfaces. You can effectively do whatever you want with these interfaces. You can make use of the base concrete implementations of the core interfaces, use a class from the MVCS implementation, implement your own concrete classes based on the framework core, bring in other libraries or any combination you can think of. In terms of a framework, Robotlegs can be whatever you want/need it to be.

Man Joel, that was a long intro. Where’s the freaking code??!?