Developers often get excited about the Robotlegs filesize footprint—adding less than 20k to your published swf. We’re much more excited about the Robotlegs cognitive footprint—how little there is to learn to get up and running with Robotlegs.

Robotlegs was always intended to be a pareto^[1] solution: it’s the 20% of functionality that solves 80% of your programming problems. The YAGNIator (YAGNI = you aren’t gonna need it!) was applied ruthlessly. This means that you can carry it in your brain’s pocket: complete use of the core Robotlegs framework only requires you to understand how to use eight classes. Yes, eight. That’s all. And these aren’t monolithic enormous classes. Most Robotlegs apps require you to make use of less than twenty methods within the framework. And Robotlegs incorporates only two custom metadata tags and, in practice, most applications only ever require the use of the [Inject] tag. More on those metadata tags later.

We’ll cover the Robotlegs API in depth but quite slowly through the following chapters. We want to help you understand why you would choose to use a particular combination of Robotlegs classes and API to solve a problem, and what the alternative approaches might be. But in case you’re craving a concrete answer to the “What is Robotlegs?” question, here’s a snapshot of the most frequently used Robotlegs code in action:

new VideoLibraryContext(rootView, true);
startup();

execute();
dispatch(event);

mapEvent(ConfigEvent.LOAD_COMPLETE, ApplyUserSettingsCommand, ConfigEvent);

mapView(DocumentTabMenu, DocumentTabMenuMediator);

onRegister();
addViewListener(TabEvent.TAB_SELECTED, dispatchDocumentFocusChange);
addContextListener(QuitEvent.QUIT_REQUESTED, hilightUnsavedDocumentTabs);
dispatch(event);

mapListener(view.yesBtn, MouseEvent.CLICK, dispatchYes, MouseEvent);

dispatch(event);

mapValue(IUserConfig, loadedUserConfigVO);
mapSingleton(UserXMLLoadingService);
mapSingletonOf(IUserLoadingService, UserXMLLoadingService);
mapClass(IPermissionRules, StrictPermissionRules);
instantiate(DatabaseKey);
getInstance(ILoggingService);

One of the potential drawbacks of using a framework is the difficulty of reusing your classes outside of that framework. Robotlegs is, by design, minimally intrusive—for example, if you create a model or service class that is used within a Robotlegs application, you should be able to re-use that class in a non-Robotlegs application by simply providing it with one ActionScript native property: an instance of IEventDispatcher.

Robotlegs commands only require you to provide an execute() method. There are no special messaging objects, just your own custom AS3 Events (or Signals if you prefer them and use the AS3Signals extension packages).

In addition, the metadata-based Automated Dependency Injection (not nearly as fancy as it sounds, we’ll de-mystify that in Chapter 4), that wires up Robotlegs applications, supports normal coding practices. Outside of Robotlegs you’ll have to wire your objects together manually, but we set a very low hurdle to jump when reusing sections of your code in projects where you’re integrating with another framework, or decide to go framework-free for optimization purposes.

From the outset, Robotlegs was intended to be easy to customize. To facilitate this, instead of being a single unit, Robotlegs is separated into three layers:

Figure 2-1. Robotlegs is a three-layer cake

The middle layer of this three-layer cake is the part that is the essence of Robotlegs. Initially the assumption was that many users would want to swap out the top and bottom layers to suit themselves.

As a result, there are very few things that Robotlegs won’t ‘let’ you do. It’s possible to implement a whole range of different patterns and architectures through Robotlegs, but we’ve actually found that newcomers tend to prefer a strong prescription. We often answer “Can I do X?” questions on the forum with “Yes, you can, but really you’d probably rather do Y”. People seem to appreciate the clarity of direction.

So, while you could apply many different top-layer architectures within Robotlegs, the vast majority of users are content with the out-of-the-box architecture—what we like to think of as the standard issue trousers for Robotlegs. These trousers are an implementation of the architectural pattern most frequently applied to ActionScript applications: MVCS (Model, View, Controller, Service).

Model, View, Controller, Service is a pattern, which separates your application’s responsibilities in a way that fits a wide range of applications.

The team behind Robotlegs is test crazy, and this has a big influence on the way Robotlegs is put together. No statics, no singletons, no reliance on display-list event bubbling. In creating Robotlegs, every single decision was subjected to the “How do I test a class that uses this?” filter.

Robotlegs makes it easy to unit test your individual classes, but it also makes it easy to integration-test features, and to end-to-end test user stories in your application.

If you’re already a test nut yourself, you’ll appreciate the reduction in setup that nicely decoupled cooperation and communication gives you. If you’ve dabbled in testing but found yourself smacking into walls relating to difficulties testing your classes in isolation, you should find that working with Robotlegs removes those problems completely. Again, the consistent approach that a strong framework gives you means that, once you’ve learned the ropes, you only have to apply real brain power to what’s unique and interesting about each part of the code when you test it.

If you’re not sold on testing, or you’ve never given it a try, we strongly recommend that you experiment with incorporating it into your workflow. Test-first development is hard—it’s hard because it forward-shifts your confusion. You can’t fiddle with your code while you ignore the fact that you haven’t really figured out what this class is meant to do, or how it’s going to fit in with the other classes in your application. We’ve found that testing is like a really (horribly) honest friend. It frequently tells you things you really didn’t want to hear right now. It’s up to you whether you listen!

The Robotlegs Way

How to get every last drop of Robotlegs goodness

While Robotlegs is intended to be flexible, don’t confuse that with ‘anything goes’.

The folk behind Robotlegs have a great deal of respect for the wisdom of the developers that forged the way in object-oriented programming, identifying patterns and best practices that they felt were valuable and transferable, and then sharing that experience so generously.

Discussions around coding best practices can get heated, but the Robotlegs forum is a space where there’s a lot of good quality and flame-free back-and-forth about good and better ways to solve specific problems. We understand that most projects are under time pressure, but we also believe that good practices and patterns largely emerge out of pain and crisis. They’re not constructed on paper; they’re the product of heuristic learning, of people repeatedly bashing their heads on the same problem until they find a way to stop a particular pain.

Robotlegs is powerful. It can quickly turn good code into a great application and can, just as quickly, turn bad code into a knotted mess. So, as well as ‘how’, we’ll also cover some ‘what’ and ‘why’—attempting to offer guidelines that will guarantee you don’t run into trouble, while also calling out the implications of breaking these guidelines so that you’re able to weigh up the pros and cons of taking shortcuts.

None of your normal AS3 OO solutions stop being relevant just because you’re using Robotlegs. Well, almost none—there are two significant exceptions:

As your codebase becomes more flexible, you’ll start to notice higher-order problems that previously never bothered you because they were obscured by more immediate difficulties. This happens to all of us. It is a great problem to have—so try to enjoy pushing through it, shifting your architectural skills to the next level, and remember to:

Robotlegs is not a Golden Hammer. Not every problem in your codebase is a nail. Specifically, Robotlegs should stay out of your views. There is an understandable temptation to use Robotlegs and Automated Dependency Injection everywhere—resist! Resist!