Robotlegs 2 is easy to jump in to. From a basic standpoint, the MVCS concepts of how to build your applications remain the same. There are some significant differences in the semantic changes with Robotlegs 2 (beta), and that is what I am going to cover here. This post will go over the changes required to port the Robotlegs 1 Flickr Image Gallery demo. I’m not going to cover the basics of Robotlegs MVCS, so if you are looking for that, I’d recommend checking out the book! Also keep in mind that this is covering the beta release and some of the API is likely to change for the full release, but that shouldn’t be radical either.
The full source for this example can be found on Github.
Building Your Context
Robotlegs 2 introduces the ContextBuilder. Instead of extending the concrete Context class, you utilize the builder that will configure your application’s bundle(s).
Within the bundle (which is an implementation of the IContextBuilderBundle interface) you make use of the install method, which will add any additional bundles and supply any configs that go along with your bundle. Let’s take a look at the ClassicRobotlegsBundle.
In essence, we are extending this bundle. It provides the tools we are used to seeing in Robotlegs 1 and allows us to make a composite bundle on top of it with out own configuration as you can see in GalleryAppConfig.
The config files are fairly similar to what you might be used to seeing within the startup() method of a Robotlegs 1 Context. There is a significant advantage to this approach that you will quickly recognize if you’ve ever had to create a ModularSignalCommandCrazyAssCompositeContext in your application before. With the Builder->Bundle->Config approach you are able to compose your applications with specific tools and extensions.
Changes to Mediators
Mediators, for the most part, function as expected. With the supplied MediatorMapExtension, you will no longer find the onRegister() method. Instead you will overrided the initialize() method of the Mediator class.
Mourning the Death of Actor
Actor was always an odd concrete class to include in the Framework by default. It is gone in Robotlegs 2. For this port, I create a BaseActor class of my own to supply the functionality that I needed for my services and models.
So there you have it…
Check out the source if you’d like to dig in a little deeper. It shouldn’t be a radical departure from what you’ve come to like with Robotlegs. I’m really stoked about the framework architecture that allows for complete pluggable composition of features. This is huge, and should really open up some opportunities for creating a robust ala carte framework that suits you and your team’s specific needs.
The Robotlegs 2 (beta): Flickr Image Gallery by Joel Hooks, unless otherwise expressly stated, is licensed under a Creative Commons Attribution 3.0 United States License.