Robotlegs. What I’m falling in love with.

Background

I just thought I’d comment on my latest endeavor at Visfleet. I’ve been a little worried about my cobbled together framework for our Flex codebase. It was designed and added too from the day we started with Flex 2 and hasn’t had a proper review since. It works, and we have workable code, but I find that the developers here have the same trouble using it over and over again. So I identified my biggest ongoing concerns:

Hard to Test Code

Sure some unit tests could be attached, but I use registries and locators for dependency injection. There are some really nice DI frameworks around now, it’s time to use one.

Sloppy Inversion of Control

IOC is sloppy due to many levels of inheritance. I use inversion of control by means of placeholder virtual methods, which after one level of inheritance still leaves us with a “call super” anti-pattern. Or with the need to add more virtual methods. I’d rather just not depend on inheritcance so often.

Namespace polution

There’s no convention in my current framework that makes enough sense when it comes to naming and positioning classes. I see Rails apps that do this so well and I get envious. Can haz conventions?

Service and Model mixed

Just don’t know what I was thinking. In the days of the mostly read only API (iVistra’s focus on visualization) I could get away with a “ListLoader” class that maintained a canonical representation of server side data using a limited CRUD command set and RESTful view of the data. RESTful is a great place to start with any service, but I think you’re a fool if you try to ‘Resourcify’ everything. It’s definitely not pragmattic, and it’s often not practical either.

[robotlegs]

This is robotlegs. Currently the documentation is a little confused about what Robotlegs is (or I find it confiusing). But here’s what I’ve gleaned from Shaun Smith (inventor) and Joel Hooks (major contributor):

[robotlegs] the DI automation framework

Robotlegs is a framework for the automation of Dependency Injection. It should be possible to plug any DI framework into it. At the moment, SwiftSuspenders is the only one successfully and completely “adapted”.

To quote Shaun:

Robotlegs aims (and does not succeed 100%.. yet) to be a set of tools for automating DI and nothing more. It’s not a DI framework itself.

It provides:

• A CommandMap - for instantiating, injecting and executing Commands triggered by an EventDispatcher.
• A MediatorMap - for instantiating, injecting and registering Mediators as view components arrive on stage in a given context
• A ViewMap - for injecting directly into view components as they arrive on stage in a given context

SwiftSuspenders

SwiftSuspenders is a simple and fast DI framework. It uses very little metadata but I find it very effective. Just try it, even if you don’t use RL, it’s so simple and effective.

[robotlegs] MVCS

Let’s call this RL-MVCS for the purpose of this discussion.

This is a reference implementation MVC framework written using Robotlegs. This is where most of the confusion arises.

When you look at Robotlegs demos, it’s usually RL-MVCS. When you look at Robotlegs discussions, it’s often about RL-MVCS. When you read the best practices documentation, it is entirely about RL-MVCS.

That said. I really like this implementation. The only thing I’d like to see made simpler is the idea of “sub contexts”, which I use for separating components and for separating modules, where a module is a largely separate “application domain”.

What [robotlegs] Addresses.

Returning to my concerns for my current framework, SwiftSuspenders adresses my sloppy IOC and DI issues directly. [robotlegs] the DI framework is even better though because:

• I get the ability to switch to a different DI framework (although I might have to write the adapter).
• I get an easily introduced mechanism for adding DI to my existing MVC implementation.
• I get documentation, open discussion and an open convention.

The conventions would help me improve my namespace pollution issues, but I’d still need to do a lot of work and document it myself. Ditto for the service/model coupling I have.

So this is why I love RL-MVCS, I get all of the RL-DI improvements plus:

• An MVC implementation that has examples, open convention, and open discussion.
• A thoroughly well thought through best practice guide.
• A framework based entirely on OO best practices. It’s actually quite hard to cut corners with RL-MVCS.
• Conventions that pry my classes apart until they are testable.
• Conventions that let me readily reduce my long inheritance chains through DI.
• Nice examples of working projects with tests in place (but not compiled into the final product, Yay!)

Also, I’ve edified myself on RL-MVCS by picking one system component of our application and only implementing it there. So right now, I have my own application mostly untouched, with just one little corner of it’s world implemented in RL to prove its value. It’s no mean feat for a MVC style framework to be able to work so readily inside another.