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/

First thought: version 2 is exactly what I’ve been trying to build with RobotLegs.

I’ve only briefly skimmed through the manual, but it really looks promising. I have some initial concerns (the use of Static methods for example; see: http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/), but need more time to play around properly.

The forum pointed me to these two handy example projects:

http://www.sitronnier.com/blog/parsley-2-basic-flex-example
http://www.sitronnier.com/blog/parsley-2-basic-flash-example

Find them on the forum here:

http://www.spicefactory.org/forum/viewtopic.php?t=247

All the Spice:

http://www.spicefactory.org/

Actors may be dependent on actors below them in the diagram, but should not be dependent on anything above them.

Commands, Services and Proxies may dispatch system events, but should never listen for them.

Mediators may both dispatch and listen for system events.

So:

1. Commands may depend on any number of Mediators, Services and Proxies, and may dispatch system events.
2. Mediators may depend on other Mediators, Services and or Proxies, and may dispatch and listen for system events.
3. Services may depend on Proxies, and may dispatch system events.
4. Proxies may depend on other Proxies, and may dispatch system events.

Why?

Check out the PureMVC FAQ: http://puremvc.org/content/category/3/23/188/

Prompted By:

This comment, thanks!

UPDATE: I somehow completely messed up the diagram when I last updated it.. I got the direction for the Service and Proxy event flow backwards.. Doh!

Constructor Injection vs Setter Injection
Constructor vs Setter Injection – Constructor is Better
Setter injection versus constructor injection and the use of required

Before I built RobotLegs I was sold on constructor injection. My prototype, however, used SmartyPants-IOC which lacked constructor injection, so I bit my lip and used setter injection. In practice I found that often, especially with framework actors, it was incredibly convenient.

Effort

Unless you use a code generator, constructor injection requires roughly 3 times the effort (more code) and is roughly 3 times more prone to human error than this form of setter injection:

public class SomeMediator

{

  [Inject] public var someView:SomeView;

  [Inject] public var someProxy:SomeProxy;

  [Inject] public var someService:ISomeService;



  public function SomeMediator()

  {

  }

}

Constructor injection requires twice the number of declarations and an extra assignment step.

public class SomeMediator

{

  private var someView:SomeView;

  private var someProxy:SomeProxy;

  private var someService:ISomeService;



  public function SomeMediator( someView:SomeView, someProxy:SomeProxy, someService:ISomeService )

  {

    // Boilerplate...

    this.someView = someView;

    this.someProxy = someProxy;

    this.someService = someService;

  }

}

Forgetfulness

Let’s consider what Misko deems the biggest problem with setter injection: forgetting dependencies.

In the case of setter injection, and in the context of the application itself (running on the RobotLegs framework), if we forget to set up a dependency rule, we’ll get a runtime error when the DI framework tries to inject into the Mediator (which happens automatically). This would be exactly the same for Constructor injection. A draw.

If we are instantiating the Mediator manually (in a unit test for example), and we don’t manually inject into it with our DI framework, then setter injection is obviously weaker – we won’t get the DI RTE, we’ll just get a null-pointer exception at some point in our test. Constructor injection is much better here, but something Misko overlooks is that constructor injection is more prone to human error from the inside. We have at least three places where we can forget to properly take care of our dependencies:

1. We might declare the dependency in our constructor argument list, but then forget to store the passed value inside our constructor.
2. We might declare a property on the class itself but then forget to ask for it in the ctor argument list.
3. We might even be so delirious as to incorrectly assign the values in our ctor by excluding “this.”.

None of those mistakes will cause a compile-time error. As with setter injection, we’ll just get a RTE at some point. Again, a draw.

When we consider what a Mediator is, and the fact that Mediators are amongst the biggest candidates for re-factoring (we might start with one Mediator for a complex nested view, for example, and then break it out into several finely grained Mediators later), setter injection becomes even more convenient. Constructor injection requires more effort when dependencies change: 3 places need editing, including the constructor’s method signature – necessitating external changes for any manually instantiated instances.

Inconsistent State

Another charge against setter injection is that it can be responsible for objects in inconsistent states: directly after construction, and before injection has occurred, the object is not quite ready for use (it’s dependencies are missing). But this isn’t much of a problem when your architectural framework handles that side of things automatically – it instantiates and injects things for you.

Hybrids In Progress, A Sliding Scale

I’d also like to touch on the mixing of injection styles. Some people see this as akin to mixing coding standards in a project – ugly. At the same time, setter injection must be used under certain conditions (circular dependencies for example), so even purists have to mix styles sometimes. I’ve chosen to roll with it, and use what makes the most sense for the case at hand. Looking at actors in the RobotLegs framework, I’m inclined towards:

• Setter injection for Mediators
• Setter injection for Commands
• Constructor injection for Proxies
• Constructor injection for Services
• Constructor injection for non-framework entities

My reasoning is that:

• Mediators and Commands generally have more dependencies and require refactoring more frequently
• Proxies and Services should have very few dependencies
• Non-framework entities are more likely to be created manually

If we look at setter vs ctor injection on a sliding scale, we have:

• setter -> constructor
• convenient -> safe

We can always migrate from setter to ctor injection as classes settle down and their refactoring likelihood decreases:

• setter -> constructor
• sketchy -> final

Mediators, by their very nature, are the sketchiest parts of an application: they are tightly coupled both to the application and the view. Commands are coupled to the application. There is very little need to make either of these actors “safe” or “final”, and for flexibility it is wise to leave them “convenient”.

Proxies and Services, however, should not be too coupled to the application. They should be the “safest” most “final” classes in the interests of loose coupling and portability. I would start with setter injection and migrate to constructor injection as those components mature.

Prompted By:

This comment, thanks!

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.

Well, you might enjoy RobotLegs AS3: yet another lightweight micro-architecture for Rich Internet Applications.

It’s got the bits that I like about PureMVC (Mediators, Commands and Proxies) without any of the bits that I’m not so fond of (Service Locator, Singletons, casting casting casting!).

I’ve put the source up on GitHub, so feel free to Fork it and make it better:

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

Discussion Group:

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

Here’s a little demo:
(Please note: the API and usage has cleaned up a lot since this demo was built)

You can also view the demo here (with view source).

The demo app is perhaps not so great, but it demonstrates many of the framework’s features. AND, there isn’t a single cast in there! No actor casting, no payload casting, not any casting, not even for fun!

I have much to say about this little framework, but it’s the wrong side of 5am and I’ve had a crazy long day. In the meantime, you can find some background info here and here if you’re interested.

Update: RobotLegs Lives!

A couple of weeks ago I played around with Mate and Swiz. I already knew a little about Dependency Injection (in theory anyway), but playing with those two frameworks really drove the point home: applications are potentially MUCH easier to write, and much more flexible, when you take advantage of Dependency Injection.

If you’ve used PureMVC you might be familiar with writing code like this:

var myProxy:MyProxy = facade.retrieveProxy(MyProxy.NAME) as MyProxy;
myProxy.doSomethingAwesome();

This is sometimes referred to as the Model or Service Locator pattern. Firstly, it’s a little tedious to write. But more importantly, it puts the responsibility on your class to “fetch” the things it needs – not a good thing (especially from a testing point of view). From the “outside” you can’t see what your class is dependant on: you have to review the actual code in your class to see what it wants to pull in from the outside world.

It’s also a bit sneaky: to get something out, you have to know how it was put in – splitting and spreading knowledge across your codebase. Not pleasant.

Alternatively, you could use a Singleton to hang all your objects on. That would not be cool: link, link, link.

Enter Dependency Injection

Another solution is to declare certain properties on your class as dependencies to be “given” to you on (or just after) construction. A Dependency Injection framework will take care of managing these dependencies and providing you with what you need. Your class can then focus on doing it’s job instead of worrying about how to get the objects it needs.

I Like The Mediator Pattern

And I like the concepts in PureMVC: Specifically the Mediator, Command and Proxy patterns. I like clean view components with absolutely no framework or application code in them – as made possible by the Mediator pattern. I like Commands and I like binding them to system events. I like Proxies, who only communicate outwards, by dispatching events, and who’s APIs must be accessed directly by Commands and/or Mediator instances.

But I don’t like the use of Singletons or Multitons, the Service/Model locator pattern, the spreading of knowledge throughout the system by the Mediator and Proxy registration and retrieval mechanism (you have to know how something was put in to get it out again), and the custom Notification scheme and it’s associated methods: listNotificationInterests and handleNotification (with that nasty switch!).

So, I like PureMVC, I just think it could be improved for certain use cases. Now, obviously, improvement is subjective. Designing a framework is largely a balancing act: every decision has a pro and a con, and the framework architect must weigh up the pros and cons to steer the project in a chosen direction. That direction is determined by the architects vision of the most important use cases for the framework. I think that PureMVC has been brilliantly designed when stacked against it’s objectives. It’s been very carefully thought through, has an amazing author and community, sports great documentation, examples and utilities, and does it’s job well.

YALMAFRIA (Yet Another Lightweight Micro-Architecture For Rich Internet Applications)

Mate and Swiz can both do Dependency Injection. What I found interesting about the Dependency Injection in Mate is that it’s event based – this allows you to look at the event target to determine the instance that is currently being injected into. Using that (and a thing called an Object Builder in Mate) I was able to configure my application to automatically create Mediators for view components as they arrived on stage, and set references to the view components on the newly created Mediators.

It worked, but it seemed a little klunky, and still required a fair amount of code to map a Mediator Class to a view component Class (and any other dependencies). Regardless, it got me amped – using Dependency Injection and automatic Mediator registration I could remove most of the boring (and brittle) code from my projects.

I decided not to use Swiz or Mate in the end. Both offer nice solutions to some of the challenges of building RIA applications, but neither would make building my current application any quicker or easier.

Besides: I didn’t like the idea of using the display list as a system event channel, as in the case of Mate, or the concept of a central (Singleton) event dispatcher, as in the case of Swiz. And I didn’t want to put ANY application or framework code into my view components, as both seem to encourage.

Also, I wanted a framework that I could use for both Flex AND plain AS3 projects. I believe that this is possible with Swiz, but certainly not with Mate.

So, I looked for an AS3 Dependency Injection library to build a(nother) micro-architectural framework on top of..

Back to Dependency Injection

I tried Spring ActionScript (previously known as Prana) first. Immediately, two things bugged me about it: the use of external xml files to configure dependencies, and the side-effect of that requirement:

When compiling a SWF the compiler ignores Class definitions that are not directly referenced by the application. A small problem, easily solved, but an extra step none the less to ensure all necessary Classes are compiled. Loading your dependencies externally is groovy, fo sho, but I really don’t need that right now.

I believe you’d enjoy Spring ActionScript if you’re from Java land (hello there, have you played with Clojure yet? it got me all jazzed for a spell.. even though I didn’t build anything useful with it).

Anyhoo.. check this out if you are interested in Spring ActionScript and Autowiring: link

Or this, if you want to see how to do a similar thing with Swiz: link

Inspired by Guice

Next I checked out SmartyPants-IOC. I liked the vibe and proceeded to build my little framework with it.

RobotLegs AS3

I decided to call my framework RobotLegs. It’s very simple really. It contains two factories (and some Interfaces):

A Mediator Factory – for automatically creating and wiring up Mediators as view components arrive on Stage.

And a Command Factory – for binding commands to events.

Everything else is handled by Dependency Injection thanks to SmartyPants. Conceptually, the framework is much the same as PureMVC, but uses DI in place of a registry, and built-in Flash Events instead of Notifications.

I was able to migrate my current project over to Robot Legs (from PureMVC) in about a day. Not bad considering there were dozens of Commands, over 20 Mediators and around 10 Proxies to convert. It was a bit of a mission creating all the custom Event Classes to replace my Notifications though.

But it was certainly worth it. My application code has tidied up nicely. Many of my Mediators, Proxies and Commands have halved in size, due to the removal of lookup code and notification body casting.

RobotLegs?

The cool thing about Mediators that automatically wrap themselves around view components as they appear is that it greatly simplifies dealing with composite, lazily instantiated view components. I don’t need to worry about how a view component comes into being, I just set up a rule that ensures when that view components arrives I have a Mediator to link it back into the application. This is great for items inside Tab Navigators, Accordians, View Stacks etc.

It does present a little problem however: context. When you manually create and register a Mediator, you have the opportunity to give it some context, such as setting a property on it. Mediators that get automatically created make this a bit tricky. We could, of course, set that property on the view component, to be picked up by the Mediator on registration, but that’s not cool – view components should be self-contained, stand-alone widgets.

My current solution is to allow Mediators to request properties from parent Mediators. This is made possible by the Mediator Factory, with it’s dictionary of currently registered Mediators and view components, and a method declared by the Mediator Interface called “provideProperty”.

I plan on releasing Robot Legs once it has settled down a bit – using it in my current project has pointed out a great many things that I had overlooked initially. It won’t be everyone’s cup of tea – nothing is

UPDATE: RobotLegs 0.1, with demo Flex app, has been released. More info here:

http://shaun.boyblack.co.za/blog/2009/04/16/robotlegs-an-as3-mvcs-framework-for-flash-and-flex-applications-inspired-by-puremvc/

Lately, however, I’ve been building an application for which PureMVC has turned out to be a pretty poor fit. The term that some people have used to describe this kind of application is “Document-Based”.

A benefit of MVC is the ability to easily create multiple Views of the same Model. Document-based is roughly the opposite of that: the ability to create identical Views of different data. Think OS X Finder (or Windows Explorer if you must!): multiple windows that look and function the same but show different parts of your filesystem.

I spend a lot of my time trying to learn as much as possible about programming. This means subscribing to a huge number of feeds and bookmarking obsessively! Looking for solutions to my current problem I re-discovered Mate. I hadn’t looked too deeply into it before as I needed an ActionScript Framework that wasn’t bound to the Flex Framework (ruling out pretty much every framework except for PureMVC). This time however, I didn’t mind binding(!) myself to Flex.

Central to Mate is the concept of an Event Map. UI components dispatch events that bubble up the display list and get caught by one or more Event Maps: loosely coupled goodness. Mate also employs Dependency Injection instead of the Service/Model Locator pattern used by Cairngorm and PureMVC. And no Singletons! Suitably impressed.

I highly recommend you check out Mate, and if I were you I’d do it in this order:

• Mate Presentation by Laura Arguello: fairly long, and a bit slow, but quite fun and covers some really important concepts – not just for Mate, but application architecture in general
• Hello Mate by Neil Webb
• Mate Overview
• Mate Document-Based Example by Theo Hultberg/Iconara: lots of great info

Ok, time for me to calculate how painful it’s going to be to switch my application over to Mate.

UPDATE: I posted my thoughts (as best as I could gather them) on the PureMVC forum here:

http://forums.puremvc.org/index.php?topic=1000.0

UPDATE: I decided not to switch to Mate for my current project. I wrote a little MVC framework (much like PureMVC), that uses Dependency Injection, and switched to that instead. More here:

http://shaun.boyblack.co.za/blog/2009/02/24/pijinnet-v3-progress-update-24-feb-2009/
http://shaun.boyblack.co.za/blog/2009/03/13/as3-dependency-injection-and-autowire/

MAJOR UPDATE: RobotLegs 0.1, with demo Flex app, has been released. More info here:

http://shaun.boyblack.co.za/blog/2009/04/16/robotlegs-an-as3-mvcs-framework-for-flash-and-flex-applications-inspired-by-puremvc/

http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html

And if you are considering using Cairngorm for your next project, give this a read (especially the comments, all of them):

http://blog.iconara.net/2008/04/13/architectural-atrocities-part-x-cairngorms-model-locator-pattern/