Feb/10
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:
Jan/10
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??!?
Nov/09
TexFlex09 Robotlegs Slides and a Robotlegs T-Shirt Giveaway
TexFlex09 was a lot of fun. I had some t-shirts printed for the event, and still have a good sized stack of them left over. I thought it would be fun to give them to people who created interesting examples, tutorials, or screen casts of Robotlegs in action. Just make something cool and post it, and I will send you a Robotlegs t-shirt (while supplies last!)
Sep/09
SlideshowPro Director via AMFPHP
I really like SlideshowPro Director. With version 1.0.9.9 and below, you could simply access it as an XML service. This was great. Very fast. Past that they reworked the application and introduced an API. This is probably a good move for many, but the API is geared towards PHP websites that want to utilize SSP Director for html/js/css purposes. What I need to do is access the resources through Actionscript 3. My first thought was use AMFPHP and simple access the API through PHP that way, but when accessing the API that way, it was dreadfully slow. It would pause while loading for a good 10 seconds sometimes. The overhead of the PHP backend and the API just don’t cut it for use as an Actionscript service.
The solution was to simply skip the middle man and go at the database directly. Now it is lightening fast using this AMFPHP service endpoint:
<?php class GalleryService { function GalleryService() { $this->methodTable = array ( "getAlbumById" => array ( "access" => "remote", "description" => "Pings back a message" ) ); } function getAlbumById($albumNumber) { $dbhost = 'YOUR_MYSQL_HOST'; $dbuser = 'YOUR_USER_NAME'; $dbpass = 'YOUR_PASSWORD'; $dbname = 'YOUR_SSP_DATABASE_NAME'; $result_array = array(); $conn = mysql_connect($dbhost, $dbuser, $dbpass) or die ('Error connecting to mysql'); $dbname = 'slideshow'; mysql_select_db($dbname); //be sure to guard against injection by casting the album id to int (thanks Shaun!) $query = "SELECT * FROM ssp_images WHERE aid=" . (int) $albumNumber; $result = mysql_query($query); while($row = mysql_fetch_array($result)){ $result_array[] = 'YOUR_PATH_TO_SSP_ROOT/albums/album-' . $row['aid'] . '/lg/' . $row['src']; } mysql_close(); return $result_array; //an array of url strings } } ?> |
There are all sorts of options you could do for this. You could set up value objects and send those back to Flash. All I needed for my purposes was the array of url strings. Simple, fast, and effective. Now we can manage our galleries with Director, and are free from the constraints of the official SlideshowPro for presentation.
What I really want is an official AMF service through Director. They are using CakePHP, and there are AMF solutions for that. Hopefully that would supply a fast, officially sanctioned AMF solution. Until than, the above works just fine.
Aug/09
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.
Kickass Books
