robotlegs/robotlegs-framework/blob/master/src/org/robotlegs/core/IContextProvider.as#L16

Don’t do that you naughty sausage! Your codebase will evolve (if all goes well), and line 16 will be replaced by a newer, shinier string of characters. Or, in this case, it’ll point to something that no longer exists.

This, on the other hand, is more likely to stick around to haunt its author (me):

robotlegs/robotlegs-framework/blob/v1.1.2/src/org/robotlegs/core/IContextProvider.as#L16

Select a tag before you link to your fancy code (“Switch Tags” under GitHub‘s “Source” menu).

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

• RobotLegs Image Gallery Demo
• RobotLegs and FlexUnit 4

I’ve also pushed out quite a couple of framework updates (currently at v0.6):

• Mediator onRegisterComplete hook -> onRegister (for those coming from PureMVC)
• Spring ActionScript adapters (as an alternative to SmartyPants-IOC)
• Namespace changed to org.robotlegs.*
• Logging now uses as3commons-logging

That last change means that RobotLegs is now dependent on the AS3 Commons logging library. It also means that RobotLegs logging is now standard, and can be easily configured or turned off. Try it out with the PowerFlasher SOS Max tool.

Module Demo

I’ve started putting together another Flex example, called the Acme Widget Factory, which can be found here:

RobotLegs Demos on GitHub

The demo is a little convoluted, but exists to illustrate a couple of things:

• Working with Flex Modules
• Communicating between Contexts via Interfaces and Events
• An alternative to Named Proxies

The demo only works with the Spring ActionScript adapters for now – due to what I believe to be a bug in SmartyPants (but I haven’t had time to build isolated tests to prove this).

The Module side of things needs a little more thought, but I think it is fairly clean and usable for the time being.

Review

As Joel mentions in one of his posts, RobotLegs hasn’t had much peer review. This is very true, and needs to be remedied (besides, I’m DYING for some technical feedback!). I have some theories as to why this is:

1. Some developers really dislike PureMVC (probably for many of the same reasons that I started RobotLegs in the first place) and so have disregarded RobotLegs because it can be viewed as a rebuild of PureMVC.
2. Many Flex developers who work on large enterprise applications seem to dislike the idea of using 3rd party Architectural Frameworks, preferring to hand-roll their own solutions on a per-project basis.
3. Dependency Injection sounds complicated to developers who are new to the pattern.
4. Many intermediate Flash developers have only just started getting into PureMVC. It will take some time for them to fully understand it’s strengths and weaknesses.
5. Experienced developers, on the other hand, are probably bored of the whole “Architectural Framework” trip, and are tired of trying out new frameworks. By now they’ve picked their favorite, learned how to be really productive with it, and have built code-generators and other such tools to work around the bad/boring parts of their chosen framework.
6. Setter injection turns some people off.. which it shouldn’t.
7. I’m not very “connected” in the developer circles. RobotLegs is my first Open Source project, and is the first time I’ve really put myself “out there”. I don’t have a very impressive online portfolio – the portfolio pieces on my blog are mostly just the small things (often built for friends) that I’m allowed to list publicly.

If you are an experienced Flash/Flex developer, and can bring yourself to review yet another framework, I would love to get some technical feedback on RobotLegs as a framework. Harsh criticism welcome.

And remember, RobotLegs is on GitHub – if you like some of it, but want to change other bits, all you have to do is click that little “fork” button and go crazy. Git For The Win!

The State Of The Game

There are some great Flash and Flex application frameworks out there right now. Mate, Swiz and PureMVC (update: and Parsley!) stand out. The authors of these frameworks realized that the Flash Platform is different enough to the JVM to warrant a fresh approach to application design.

Someone mentioned recently that for such a young language (referring to Action Script 3), it’s quite surprising how many frameworks have sprung up around it. I’m not surprised at all: rich internet application development is complicated.. and it’s a pretty recent field in the grand scheme of things. It brings new (and often subtle) twists to traditional web and desktop software development. Writing elegant, maintainable code is hard enough as it is, but doing so on a rapidly evolving, heavily interactive platform.. well, people are still working on the best way to approach that (unless I missed the big news – in which case you can stop reading right here).

Hence all the groovy new architectural frameworks popping up. They share some common goals:

1. Help developers write good, clean, understandable, testable, maintainable code
2. Help them write that code faster
3. Provide an easy-to-use mechanism for application/context/module subsystem inter-communication
4. Provide an easy-to-use mechanism for wiring distinct parts of the application together whilst keeping those parts loosely coupled

And they succeed. To various degrees. I think they’re all pretty cool.

A Poke In The Back With A Sharp Stick

So why build another one?

1. For fun – it’s how I learn stuff
2. Because I find the other frameworks critically flawed

What kind of “critical” flaws?

1. Singletons (big “S”)
2. Central/Static Event Dispatchers
3. Using the Display List as an Application Event Bus
4. Casting
5. The Service/Model Locator Pattern
6. The Presenter Pattern
7. Injecting into View Components

And what’s wrong with those things?

They are bad ideas:

1. The Singleton – Bad Idea

The standard Singleton implementation (that static getInstance method) is severely flawed. Unless you are writing device drivers, there is almost no excuse to touch a Singleton with a sharp stick.

Singletons bring bags of hurt to frameworks and applications.. suddenly, trying to build a modular application becomes an overly complicated affair, and unit testing becomes a nightmare. Singletons are viruses – they infect every class they touch.

And Multitons? If Singletons are evil, Multitons are diabolically evil. What makes the Multiton pattern incredible is that it manages to chump the Singleton as the worst Design Pattern Of All Time – no easy feat, and certainly the work of an evil genius with a wicked sense of humour. Not only do we have all the problems of the classic Singleton, we throw a poorly designed Model Locator into the mix – to pull out these horrendous Singletons we now need to use String keys.

Contextual singletons (as made possible by Dependency Injection frameworks) are a much nicer solution, they don’t require any extra (fluffy, nonsense, ill placed) code on the target classes themselves, and they allow identical applications/modules to exist side-by-side in the Virtual Machine without fighting and mass confusion. Which leads me to..

2. Central/Static Event Dispatchers – Bad Idea

As convenient as it is to use, a Central Dispatcher is a really bad idea. Another Singleton effectively. Pop two apps into the same SWF and watch, with excitement and glee, all the cross-talk that occurs – both apps responding to each other’s events. Oh noes!

Architectural frameworks generally provide you with an application event bus/channel/dispatcher to “chat” on, but this should be localised to the application itself (or some other context). Which leads me to…

3. Using the Display List as an Application Event Bus – Bad Idea

I find this one fairly disturbing too: dispatching system/application events along the display list. No!

A View is just that: “A view”, not “The view”. And don’t get me started on those innocent looking Event Maps! No, let’s move along…

4. Casting – Bad Idea

Besides wasting space and annoying programmers, casting distributes knowledge throughout a system – casting requires that you look elsewhere in your codebase for the “real” type.

And it weakens our lovely compile-time type checking (albeit temporarily), sending us back in time to our unhappy days building complex applications in the Flash IDE. And it’s boring. And it often occurs because of..

5. The Service/Model Locator Pattern – Bad Idea

Classes should not be responsible for “fetching” their dependencies – this is a separate responsibility that belongs somewhere else entirely – they should only contain code for doing their job. When classes reach outside to fetch things from the application/context they sneakily hide their dependencies away from the outside world.

Unit testers will despise you (which is a serious problem if you are writing your own tests) because it becomes incredibly hard to figure out how much set up needs to be done to write even the smallest of tests. You have to look inside the class for any calls to the Service Locator to find your direct dependencies, and then you have to look inside each of those classes to find theirs and so on. No no, that’s just cruel.

6. The Presenter Pattern – Bad Idea

Ok, it’s going to be tricky to back this one up. But think about it this way: the Presenter pattern requires that you modify your View component (to add a reference to a Presenter). Not a biggie, but once you’ve done that you’ve started coupling your View component to your application/context – a slippery slope.

I think the Mediator pattern is a much better fit for Flash and it’s Display List, and even more-so when it comes to Flex (and other UI frameworks with complex component life cycles).

It is far easier and cleaner to “wrap” around view components and poke their APIs than to have to modify (extend) them to make space for their Presenter references. Leave those components alone, leave them to the component developers, you’re supposed to be writing an application. While we’re on the Presenter pattern, let’s take a look at something dirty one might do in an attempt to salvage it’s reputation..

7. Injecting into View Components – Bad Idea

Besides being incredibly slow and wasteful (especially for Flex UIComponents), injecting directly into a View component couples it to your application/context.

View components, with any hope for reuse, should be as self-contained as possible. They should expose an API and dispatch Events. They shouldn’t be dependent on the application they are in or the framework it happens to be using. Give ‘em ViewModels (M-V-VM) if you must, but don’t go and couple those ViewModels to your application, and certainly don’t inject them.

Wrapping Up This Micro-Post

Well that’s just your opinion, dude

Yeh, but I’m pretty proud of my little 7 point list there (cos I’m an OOP noob, and this stuff gets me amped). Using Dependency Injection I was able to avoid all those nasty things when building my own PureMVC-like framework.

But that just shifts the problem somewhere else

Yes, somewhere more appropriate.

Besides some convenient implementations (in the mvcs package), and some marker interfaces (in the core package) RobotLegs essentially provides two things:

1. A Command Factory – for binding Commands to Events, and
2. A Mediator Factory – for handling automatic Mediator creation and registration

Everything else is handled by a Dependency Injection framework and an Event Dispatcher.

Note: If you’ve been through all this before, I apologise, it’s new to me.. I’m a little slow.

Beware: the current default implementation of RobotLegs makes use of annotated setter injection. This breaks encapsulation, is open to misuse, and runs the risk of leaving objects in partially initialised states, but it’s very convenient! You can swap out SmartyPants-IOC for a Dependency Injection framework that performs constructor injection if you really want to play it safe.

I’ll admit straight-up (albeit as a footnote) that I never really gave Cairngorm much of a chance – preliminary research led me to demos, documentation and diagrams that screamed poor design and foreshadowed immense struggle. I’m sure there is a way to build a well designed Cairngorm application, but it looks like it’d take an awful amount of effort.. and code. And it probably wouldn’t be very much fun.

UPDATE: Removed some words that made me sound like a douche bag.