How to Use RobotLegs On Top of Gaia: Part Deux

Robotlegs has been released for awhile, and things have changed over the past 7 months for the better.  A major discovery at how the Flash IDE can compile metatdata has recently come to light, so it’s time for an update to this topic which hopefully supersedes both my old way of using Robotlegs in the Flash IDE, and Helmut’s way.

The following article describes what Gaia and Robotlegs are, why you would use them, and how you go about using them together.


Gaia: A framework for building Flash websites with built-in deep linking, modules, and code generation.

Robotlegs: A MVCS framework for Flex, Flash, and pure AS3 applications.


Gaia is great for building websites, but it’s just a platform for you to build on, a bunch of helpful scaffolding; it doesn’t prescribe a way to build your applications.  Specifically, you have to write your own code for Business logic and Application/Domain logic.  You still have to write code to hit back-end services, parse the returning XML/JSON/AMF, and act on that data.  You can do this just fine for smaller websites in Gaia; Gaia doesn’t get in your way, nor prescribe how to build your site.  However, for larger sites, it may get confusing on who does what, where that code goes, and how to work with other developers.

This is where an application framework like RobotLegs comes in.  You’re domain model goes in the Model classes, your Business logic goes in the Service classes, and your Domain/Application logic goes in your Commands & Mediators.

Examples: If a logged in User object needs to be persisted globally across pages in your site, put it on the Model.  If you have a large amount of web services to get dynamic data from, and each is different, some requiring parameters, create Services out of them.  If you need to do different things depending upon which user is logged in, and what permissions they have, utilize a Medaitor/Command for such code.  Gaia can just handle the state of your application and what it looks like.

Gaia builds your site, and RobotLegs makes it work with dynamic data.

While you can utilize this combination on smaller websites, it is recommend for larger, Enterprise sites.  Metrics include more than 12 pages each requiring dynamic data from a live middle tier, more than 10 web services, and/or a significant amount of application logic that the server doesn’t handle.


  1. Setup your Gaia project.
  2. Drop your Robotlegs SWC into the “libs” folder.
  3. Check “Export SWC” under File > Publish Settings.
  4. Add the Robotlegs SWC to the Library Path (File > Publish Settings, Flash tab, Settings Button, Library Path tab, Browse To SWC button).
  5. Open and instantiate your Robotlegs Context in the overridden “onAddedToStage” before it calls super, passing it “stage” as the first and only parameter.
override protected function onAddedToStage(event:Event):void
	stage.align = StageAlign.TOP_LEFT;
	stage.scaleMode = StageScaleMode.NO_SCALE;
	mainContext = new MainContext(stage); // notice before super

For Mediator’s, instead of a View reference, create an interface, and use a String for the class in mapMediator (more info below).


Mediator’s are little tricky since Gaia is built on top of modules.  Since you don’t want to defeat the purpose of using modules in the first place, having separate SWF’s each containing unique content to save download/initialization time/memory usage, you need to utilize Robotleg’s built in support of this workflow.

Mediator’s can be created for Gaia Page classes, or View children of a Gaia Page class.  Not all Gaia pages necessarily need Mediator’s, only those that wish to interact with Robotlegs.

  1. Create an interface for whatever View you wish to have a Mediator for; put the functions your Mediator needs for the View to have in the interface.
  2. Have your View implement this Interface.
  3. When registering your Mediator in the Context, do it like so:
mediatorMap.mapView("yourViewClass", YourMediator, IInterface);

First, notice the 1st parameter, the class name, is a String instead of a strongly-typed class name.  This ensures that your main.fla does not compile your View code into your main.swf.  It is only downloaded, initialized, and loaded into memory once the user navigates to that page.

Second, notice the 3rd optional parameter is the interface you created.  This ensure’s Robotlegs know’s what class to look for to be Mediated when the Gaia page is navigated to and your View comes onto the DisplayList, and thus create your Mediator with it’s injected View.  This also ensure’s you can still get strong-typing while talking with your View in your Mediator.


For larger applications, I would encourage the use of Flex.  However, for multimedia heavy sites, it’s a lot easier to utilize Gaia since it already has modules built in, they are easier to work with and unload than Flex modules, as well as all the other media centric features that Gaia comes with.  Also keep in mind that just because you utilize Robotlegs doesn’t shield you from dependencies like Flex does via -load-externs.  If you have a Gaia page class that imports a class that has dependencies, that Gaia page will import them, either negating the positives that modules give you or causing your application not to work/compile.

When building Flash websites, it’s a given you’ll probably utilize Gaia.  For larger sites, though, you may wish to utilize a framework to help manage the large amounts of code you’ll accrue for hitting a variety of services, as well as managing application logic (if the user is logged in, do this, else do this).  Robotlegs is a fine choice because of it’s support for dynamic Mediators through the use of Interfaces shown above.

Questions about Gaia?  Documentation | Forum

Questions about Robotlegs? Documentation & Forum

5 Replies to “How to Use RobotLegs On Top of Gaia: Part Deux”

  1. Glad to see the post…was starting to worry you’d never come back from iphone land.

  2. There are different ways to bootstrap RObotLegs on Gaia instead of using Main. If i used the “indexFirst=”true” option, my index page could do the bootstrapping off an externally preloaded IMovieClip asset which has the RobotLegs app logic. This allows me to map services and other stuff prior to calling super.transitionInComplete and IMovieClip.content.initRobotlegs(). IGaia can be mapped as a service in RobotLegs for any menus/widgets in the site instead of using the singleton bridge reference.
    Personally, for better declarative control, I tend to adopt manual mediation routines which allow me to mediate assets and custom-map them to multiple interface variables through a generic Inject(name=”view”) attonation within my mediators. This allows me to map a view component to multiple interface signature variables, rather than RobotLegs automatic-mediation restriction of a single view component type to be mapped.

Comments are closed.