Robotlegs, AS3-Signals and the SignalCommandMap Example
Robotlegs and AS3-Signals play really well together. Both apply solid object-oriented principles to accomplish their respective goals. Signals is extremely well suited for automated Dependency Injection. By combining Signals and Robotlegs you are able to eliminate the use of Flash Events in the framework layer of your application. Eliminating Events means eliminating the ambiguity that can accompany Events and their String registry based approach to the Observer pattern. Signals provides a strongly-typed object-oriented approach to this same pattern.
With the standard Robotlegs MVCS implementation you leverage the events provided by Actionscript 3 to communicate amongst the various actors of an application. From models and services dispatching notifications of their actions to triggering commands, events are a core piece of the implementation. To facilitate the use of Signals within MVCS it was necessary to create an extension to allow for Signals to be registered as Command triggers. This need spawned the SignalCommandMap utility.
The SignalCommandMap extends the normal MVCS context and creates a SignalContext. The SignalContext instantiates and provides access to the SignalCommandMap alongside the other maps that are standard to Robotlegs. The SignalCommandMap allows you to map Signal classes and instances to commands that will be executed when the Signal dispatch() method is called. The value objects that are passed in the dispatch are then injected into the command alongside any other mapped injections you have created.
Let's take a look at a simple example that makes use of the SignalCommandMap and discuss some of the underlying code to see how it works:
Robotlegs Image Gallery Example using AS3-Signals and the Presentation Model
Jason Crist posted a thought provoking request for his upcoming presentation comparing Robotlegs and Swiz. He's got a clever knack for stirring the framework ant pile and getting developers eyes off their IDEs long enough to discuss their passions. In this case the developers include Ben Clinkinbeard, Shaun Smith, Jesse Warden and myself.
These conversations are always good natured. While we work on (or use) "competing" frameworks there is always a sense of mutual respect. We like our tools but have obvious inclinations towards the projects that we've invested our hearts and souls into.
Ben Clinkinbeard has pointed out (several times!) that Robotlegs is all about extending the MVCS classes. My stock answer is that there is a clear separation between the framework and the concrete MVCS implementation. To paraphrase Ben, "Well show it to me then!"
All of the "official" Robotlegs examples are making use of the MVCS implementation. Why? Because it is solid, recognizable, and fairly easy to get one's head around. It provides a common ground for developers and a set architectural structure which is a huge advantage in any team environment. It is important to make the distinction between the framework and the MVCS implementation. What does that even mean? At the core, Robotlegs is a modular set of tools to provide a convenient mechanism for wiring applications. Robotlegs is not doing class reflection. Robotlegs is not an automated dependency injection solution. Robotlegs is an adapter to a dependency injection solution,by default the lightweight SwiftSuspenders library. Through a set of tools, namely the MediatorMap, CommandMap, ViewMap, and the injection adapter Robotlegs provides a robust starting place to begin coding your application.
The MVCS implementation is a set of base classes loosely modeled on PureMVC. At the heart of the implementation is the Context. The Context creates instances of the various mapping classes, the injection adapter, and gives the developer a centralized IEventDispatcher that can be used for messaging between application tiers.. The other three classes, Actor, Mediator, and Command, reduce boiler plate and provide convenient access to injected dependencies typically used in the the MVCS tiers.
What if you hate PureMVC, don't want to extend any framework classes, or generally just want to work in a different way outside of a prescribed MVCS architecture?
No problem.
Here's the deal. Robotlegs, the framework, is a set of interfaces. You can effectively do whatever you want with these interfaces. You can make use of the base concrete implementations of the core interfaces, use a class from the MVCS implementation, implement your own concrete classes based on the framework core, bring in other libraries or any combination you can think of. In terms of a framework, Robotlegs can be whatever you want/need it to be.
Man Joel, that was a long intro. Where's the freaking code??!?
Robotlegs IoC/DI Flex Framework Examples Updated
Live demos are available on robotlegs.org here
Acme Widget Factory:
The Acme Widget Factory is modular example and deals with loading multiple modules into a shell and communicating between those modules. The shell and each module has its own context.
Lazy Stack:
Lazy Stack is an example of deferred instantiation of Flex components, and how this is handled by the Robotlegs framework.
Wheres Window:
Where's Window is a simple example to show how to mediate and communicate between a set of instances of the same view component that have individual mediators. In this case, the view components are windows in an AIR application. This uses a proxy to register and manage the currently open unique windows. I am going to write a more detailed breakdown of this particular example soon.
The Elevator Pitch
Robotlegs is an IoC/DI container that is modeled on the PureMVC application structure. It is designed to be MVCS, model-view-controller-service, providing metadata dependency injection across these layers. While following the well organized approach of PureMVC, it eliminates the use of framework singletons and takes full advantage of the Flash Platform to keep the dreaded boiler plate code to a minimum. Eliminating these singletons makes unit testing and TDD much easier, which can be a real struggle when trying to isolate classes for testing where these singleton dependencies exist. Robotlegs is fast, clean, and perhaps more importantly fun to work with. There is a smorgasbord of architectural frameworks available for Flex/AS3, but Robotlegs is worth a look even if you are sick of looking at architectural frameworks.
Unit Testing: IoC/DI, Robotlegs and FlexUnit 4
I've been reviewing the various IoC containers available for Flex/Actionscript. One of the benefits of IoC and DI is that it greatly facilitates unit testing. By injecting our dependencies into our applications actors, we are effectively isolating them from the other classes that make the application function. "So what?"
In computer programming, unit testing is a software verification and validation method in which a programmer tests that individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a class, which may belong to a base/super class, abstract class or derived/child class.
Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation. -wikipedia unit testing entry
To effectively unit test classes, we want them to be as isolated as possible. The class needs to stand on its own and have its functionality vetted to ensure that it behaves as expected. When we start to test how our classes behave together, we have entered the land of integration testing. Integration testing is a worthwhile pursuit also, but before we get to that point, we really want to ensure that our classes are solid by themselves.
Using the example in this Robotlegs Image Gallery demonstration, we are going to test a couple of the classes that make up the application. The demo isn't complex. It has a very simple model, a single service, and just a few views. In fact, it might even seem like a waste of time to unit test a simple example such as this, but the concepts are applicable to larger applications where the benefits of this type of testing really start to pay off.
FlexUnit 4 is the framework that is used here. It provides very handy asynchronous testing, meta data support, and a whole bucket of stellar features that I won't even begin to scratch the surface of. FlexUnit 4 also comes with a graphical testrunner interface:
Inversion of Control and Dependency Injection with Flex using the Parsley Application Framework – Part 2
This is the second part in a series exploring Inversion of Control and Dependency Injection containers available for Flex. In the first part of the series we discussed what IoC and DI are and how they can benefit our applications. In this part, we will explore the Parsley IoC Container through a simple image gallery application.
Here's the source on github...
Inversion of Control and Dependency Injection in Flex using the Parsley Application Framework – Part 1
The Inversion of Control (IoC) design principle and the related Dependency Injection (DI) design pattern have been around for several years. In the Java world, popular frameworks such as Spring make heavy use of these concepts. With the introduction of Actionscript 3 in 2006, the opportunities for framework development increased greatly. As the community matures, we are starting to see robust tools appear on the development landscape. It is a good time to be a Flash geek!
Through this series of articles, we will delve into the Parsley application framework and look at how it implements IoC and DI in the context of a photo slideshow. Through this example we will look at bootstrapping the container, connecting to services, and populating our components with the results. In this first part, we will get an overview of IoC and DI and talk about some of the benefits and drawbacks of using these concepts in our applications.
So what's up with PureMVC Commands anyway?
That is what Jesse Warden (JesterXL) asks the fine folks over at the PureMVC forums. Cliff gives a good rundown on the why/when/how of PureMVC Commands.
PureMVC's relatively light use of commands, when compared to other widely used MVC frameworks, tends to make one think they are doing something wrong. This isn't really the case. Commands are still viable actors in our applications, but many times the shortest route is the best route. PureMVC doesn't force us to use them, but gives us access when we need to.
I generally use PureMVC Commands for actions that can be initiated from several places, as well as for application startup. I've also found them very useful for popups and AIR window management.
Fabrication – Simplified PureMVC multicore modules (and more)
One of the many reasons I love PureMVC is the community of highly intelligent, skilled, object-oriented (oriented) programmers that are constantly using the framework to build new and interesting utilities. This is a by-product of the very nature of PureMVC. Cliff architected the core framework in such a way that is is truly simple, providing a base from which to build new useful structures.
Fabrication, a new utility developed by Darshan Sawardekar is a shining example of this fact. He has taken the PureMVC multi-core apperatus, combined it with Cliff's Pipes utility, and created a wonderfully abstracted means for creating modular PureMVC applications. Not only does this simplify the connection of modules in your application and allow them to communicate seamlessly, but he provides a router/firewall metaphor for controlling the communication as well as undo/redo functionality.
Thanks Darshan, your efforts are appreciated. And as always, thanks Cliff for providing the base from which our community can build and contribute. Cheers.
Refactoring: Improving the Design of Existing Code
My code smells bad. There is no doubt about it. As soon as I read that metaphor my head was nodding with understanding. This book is a classic, and I recommend it to anybody that wants to improve their coding habits and create more flexible applications that don't make you sad and angry.
It is a thick volume, but 2/3s of the text is the catalog of refactorings. This makes the text describing the concepts of refactoring a relatively short read. Mr Fowler guides you through the process, providing a simple example and clearly explaining the thought processes involved. The catalog covers a wide range of common approaches to refactoring an application.
Enumerating data types in Actionscript 3 (AS3)
In computer programming, an enumerated type is an abstract data type used to model an attribute that has a specific number of options (or identifiers) such as the suit of a playing card (i.e. a Club, Diamond, Heart or Spade). Using this type allows the program to handle the attribute more efficiently than a string while maintaining the readability of the source code.
-from Wikipedia
I've found this method (illustrated in code below) for enumeration of datasets to be useful, and at this point even essential, in my applications. Prior to this I was actually cutting and pasting the arrays that I was using in my various combo boxes and other selection components as dataProviders. By breaking the dataset into an enumeration class, it makes it easy to maintain the list and lets the dataset function as a first class citizen, ensuring that your data is consistent throughout the application.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 | package enum { /** * CloudTypeEnum enumerates cloud types. * @author JHooks * */ public class CloudTypeEnum { public static const NONE:CloudTypeEnum = new CloudTypeEnum( "None", -1 ); public static const CUMULUS:CloudTypeEnum = new CloudTypeEnum( "Cumulus", 0 ); public static const STRATUS:CloudTypeEnum = new CloudTypeEnum( "Stratus", 1 ); public static const CIRRUS:CloudTypeEnum = new CloudTypeEnum( "Cirrus", 2 ); public static const NIMBUS:CloudTypeEnum = new CloudTypeEnum( "Nimbus", 3 ); public var value:String public var ordinal:int /** * CloudTypeEnum constructor * @param value * @param ordinal * */ public function CloudTypeEnum( value:String, ordinal:int ) { this.value = value; this.ordinal = ordinal; } /** * A list of cloud types * @return * */ public static function get list( ):Array { return [ CUMULUS, STRATUS, CIRRUS, NIMBUS ]; } /** * A list of cloud types appropriate for use in ComboBox and other * selection components as a DataProvider * * myComboBox.dataProvider = CloudTypeEnum.cList; * @return * */ public static function get cList( ):Array { return list.unshift( NONE ); } /** * Select a cloud type by its value property * @param value * @return * */ public static function selectByValue( value:String ):TaskTypeEnum { for each ( var cloudType:TaskTypeEnum in CloudTypeEnum.list ) { if ( value == cloudType.value ) return cloudType; } return NONE; } } } |
Thanks to Cliff Hall who showed this to me via one of his PureMVC demo applications. For the life of me I can't remember which one.
