Swiz, AS3-Signals, and [Inject] FTW
AS3-Signals is a recent project by Robert Penner as an alternative to Flash Player’s native event system. While I don’t personally have (m)any problems with events, I have been curious about Signals and keeping an eye out for an opportunity to try it, especially in conjunction with Swiz. That opportunity presented itself a few weeks ago, when Joel Hooks finally showed me the world that Robotlegs can be used without extending framework classes all over the place. As he says in the post, I had been asking to see that for a long time, because I cringe at frameworks that mandate lock-in via inheritance.
In looking at Joel’s sample application (which I think is very good), I noticed that it was very similar to a Swiz application. The application is configured using a context class, which is virtually equivalent to a Swiz instance used to configure an area of a Swiz application (or a whole application). So I spent about 15 minutes and took the latest Swiz SWC I had, created a Swiz instance that mapped to his context, put it in the context’s place, and voila; I had the same application running on top of Swiz. Literally the only other thing I had to do was to add a single [PostConstruct] metadata tag. You can see the striking similarities below. Edit: I have now also included the same Swiz configuration as it would look in ActionScript.
Swiz config in MXML
RobotLegs config
Swiz config in ActionScript
You can even take the resulting application and switch the framework it’s running in by simply commenting/uncommenting the ImageGallerySwiz and ImageGalleryContext lines in index.mxml
Working with Signals couldn’t be simpler, and Swiz supports them right out of the box. In fact, I couldn’t help but be amused by the fact Swiz had better native support for them than RobotLegs did.
They are simply defined in a BeanProvider like any other dependency, and then work as expected. The [PostConstruct] I added was on LoadGalleryCommand’s execute() method, and it replaces the last line of ImageGalleryContext’s startup() method.
Summary
I really like the fact that applications can be somewhat interchangeable between the two frameworks now that we’ve settled on [Inject]. I think a reasonable degree of portability is a sign of a good framework, and based on this example you can see that both RobotLegs and Swiz meet that criteria. The obvious question then, is why pick one over the other? Some of it surely comes down to personal preference, but beyond that I think it is a question of power, scalability, adaptability and developer productivity. In future posts, I will show how Swiz is the clear winner in those categories.
Enjoy!
You can leave a response, or trackback from your own site.

Nice exercise!
I’m also enjoying the flexi-ness of the RL framework. I’m using Signals (with Joel’s RL utility) and the conventional event model alongside each other and it’s all shockingly easy to use.
On the personal preferences, I guess it just depends how much brain space you want to occupy with wondering what the hell a BeanProvider is…
Like you say – the portability from one framework to the other is a really nice testament to cooperation and consideration of the wider picture. I love the idea that a modular app where one dev works in RL and the other works in Swiz wouldn’t be a nightmare.
LOL, I don’t think I’d recommend using them in the same project, but easily acclimating to one from the other is definitely cool. As for BeanProvider, how long did it take you to figure out- 10, 15 seconds?
Very cool. Definitely curious to see how Swiz is “better” than Robotlegs (because I’m quite smitten with Robotlegs). Would be particularly interested to see the differences in terms of the controller tier (comamnds, etc.).
What would the AS3 equivalent of the above look like in Swiz? I’ve held off on adopting Swiz because of it’s MXML but it sounds as if you dual-support AS3/MXML now?
I don’t know why, but I still despise the left-over-Java nomenclature of “bean provider.” I know that’s incredibly petty, but it drives me up the wall.
Very happy to see you added “Inject” alongside “Autowire”!
Hey Troy,
I updated the post to show the same Swiz config defined in ActionScript.
As I mentioned, I think where Swiz surpasses RL is in terms of developer productivity, scalability and flexibility. As for the “controller tier”, there really isn’t one unless you want it. You can very easily use the Command pattern with Swiz if you prefer it. Maybe I should post an example of that?
And finally, yea, stop being so petty.
Ben
Nice Ben, in further tweaking of Swiz/Signals/Robotlegs, I would have to agree that just dumping your signals in your beans with Swiz works out very nice. I always feel a little cleaner when I don’t have instantiated Swiz’s in my apps.
Nice. Was not aware you can config Swiz in as or mxml.
If you can provide a post with example of command pattern with Swiz that would be great!
[...] So, previously I had talked about using Swiz and AS3-Signals (Swignalz!). My example was crude and honestly, it was not good. Ben Clinkinbeard did a much better job of showing how easy it was to drop some AS3-Signals around with Swiz. [...]
[...] Swiz Swiz, AS3-Signals, and [Inject] FTW [...]
[...] Hooks created this RobotLegs/Signals demo. Ben Clinkinbeard then created this Swiz-version of Joel's demo. I then took Ben's demo and Swiz-ified it even more by using a custom [...]
I’m not sure what you mean by Swiz having better native support for Signals than RobotLegs. The signals utility Joel put together is really just for being able to map a signal to a command, which you don’t do here anyway. “Natively” in RobotLegs I could map a signal as a singleton instance and inject it into other classes in my app no problem.