A few days ago I stumbled upon Swiz, which bills itself as the "brutally simple micro-architecture for Rich Internet Application development with Adobe Flex." If the term micro-architecture or the buzzword Rich Internet Application haven't scared you off yet, read on, because it really is a lovely little framework.

Swiz is a lightweight framework for Flex (and ActionScript) that lets you separate your business and presentation logic and implement a loosely-coupled event-based architecture in your applications. I've purposefully stayed away from using the terms Inversion of Control (IoC) and Dependency Injection (DI), even though Swiz is, at its core, an IoC framework that lets you carry out DI. The reason? I feel people get too caught up on the fancy names and either get scared off or end up blindly implementing patterns and frameworks without really understanding what they're doing or why they're doing it. Thankfully, Swiz is simple enough that you can actually understand what it does and why it does what it does. And, it doesn't pigeonhole you into a color-by-numbers straitjacket or suffocate you under a mountain of boilerplate code like some other frameworks.

This blog post is not meant to be an introduction to Swiz. For that, read the Getting Started guide, watch the introductory video by Swiz creator Chris Scott from his presentation at 360Flex last year, and read the Swiz posts on Sönke's blog and those on Chris's blog.

Instead of an introduction, I want to document how I'm using Swiz and the modifications I've made to it in hopes that they might help other developers and possibly spark conversation on future features.

Open a window, let some AIR in

(Sorry, I couldn't resist!)

I ran into a couple of issues with Swiz when I finally got the chance to play with it yesterday. First off, I couldn't get the autowiring to work with new Window instances in AIR. Googling around, I found that this was a known issue and that Sönke had already applied a fix in the form of a registerWindow() method that you call before opening your window. The fix, however, didn't work for me without an additional little patch to manually force the autowiring on the Window class itself. So my registerWindow() method ended up looking like this:

public function registerWindow(window:IEventDispatcher):void
{
    window.addEventListener(Event.ADDED_TO_STAGE, handleAutowireEvent, true);
    window.addEventListener(Event.REMOVED_FROM_STAGE, handleAutowireEvent, true);
    autowire(window);
}

With that little change, my new Window instances get autowired correctly.

Wrrooom, wrrrrooom!

I also saw that the autowiring code was causing quite a bit of performance slow-down. So I decided that autowiring should be opt-in. I modified the framework so that only classes that have a public autowire property declared are autowired. I usually declare this in my classes like this:

public var autowire:Boolean = true;

I could have made it so that I used a metadata tag instead but the whole idea was to stay away from the overhead of describeType. (I'm not sure what additional overhead describeType's XML conversion adds on to the internal describeTypeJSON method but I have a feeling it's quite substantial. If so, it would probably be nice to have a method to just return metadata for a given class — in the spirit of getQualifiedClassName — to make it more performant to parse metadata at runtime.)

So my handleAutowireEvent() method in the Swiz class looks like this now:

private function handleAutowireEvent(e:Event):void {
	// Autowiring is strictly opt-in for performance/efficiency, and
	// having an explicit flag in the class should make your intent clearer.
	if (e.target.hasOwnProperty("autowire")) {
		autowire(e.target);
	}
}

Similarly, the handleRemoveEvent() method simplifies to:

private function handleRemoveEvent(e:Event):void {
	if (e.target.hasOwnProperty("autowire")) {
		_beanFactory.unwire(e.target);
	}
}

The performance increase has been striking: the overhead of Swiz, with this change, is entirely negligible whereas before I was experiencing a doubling in the initialization time of my app.

In case you make the same changes, you should also update registerWindow() (hey, every cycle counts right? Or something like that!):

public function registerWindow(window:Window):void
{
    window.addEventListener(Event.ADDED_TO_STAGE, handleAutowireEvent, true);
    window.addEventListener(Event.REMOVED_FROM_STAGE, handleRemoveEvent, true);
 
	// Fire the autowire manually for the window itself.
	if (window.hasOwnProperty("autowire")) {
		autowire(window);
	}
}

Flex Framework? How about ActionScript and Flex Framework?

I'm also using Swiz quite differently to how it was originally intended. Originally, you're supposed to declare your beans (beans? What are we Java?) in MXML. I found this unnecessarily limiting. So I declare my beans (or components; since neither ActionScript nor Flash are a type of coffee) in ActionScript. And, although I'm using Swiz on a Flex app currently, I don't see any reason off the top of my head why you couldn't use it in ActionScript-only projects too.

Here's a sample Beans class in ActionScript showing you how it's done:

package com.mydomain.myawesomeapp
{
	import org.swizframework.util.BeanLoader;
 
	import com.mydomain.myawesomeapp.SomeController;
	import com.mydomain.myawesomeapp.SomeService;
 
	public class Beans extends BeanLoader
	{
	        // Simply instantiate and return an instance...
		public function get someController():SomeController {
			return new SomeController();
		}
		public function set messageController(o:*):void {};
 
              // ... or do some configuration beforehand
		public function get someService():SomeService {
			var someService:SomeService = new SomeService();
			someService.configureSomething("like", "totally", "cool");
			return someService;
		}
		public function set twitter(o:*):void {};
 
		public function Beans() {
			super();
		}
	}
}

So, basically, what we're doing is mimicking the methods in the ActionScript class that would have been generated from the MXML (or, more precisely, giving Swiz exactly what it's looking for in the BeanLoader, which are readwrite accessors; this is why we need the setter even though it doesn't do anything.)

And, finally, a gotcha that I find myself falling into: Remember to make anything you're going to [Autowire] or [Mediate] public. This means the properties that will receive the class instances and the event handlers. Since you'll be used to automatically making these private, take extra care!

In closing

Swiz is a lovely, lightweight framework that I'm really enjoying working with. It also has a small but active community and some good developers behind it. Play around with it, why don't 'cha and let me know what you think of it in the comments!

Cue the emergence of a viable alternative to Google App Engine.

I'm interested in seeing the direction that Joyent takes this.

I've just tagged Gaebar Beta 3 (version 0.3) in GitHub.

This is a bugfix release, with changes almost entirely submitted by or suggested by the community.

Thanks go to gumptionthomas, Martin Kleppmann, Tony Andrews, Rafal Jonca, and, of course, Guido van Rossum, for your patches and feedback.

Changes in Beta 3

• Merged gumptionthomas's pull request (commit)
  • Fixed unicode and escape string issues with key_names
  • Properly reference InternalError as db.InternalError
• Applied patch by Martin Kleppmann (commit)
• Backup doesn't blow up when there are non-backup files/folders in the backups folder. (e.g., if your project uses SVN)
• Updated the readme.txt based on Guido's feedback (commit)
• Added note to readme.txt regarding getting more detailed exceptions (thanks to Tony Andrews; commit).
• Applied patch by Rafal Jonca (commit):
  • Key names may now contain unicode
  • ReferenceProperties can now be created with keys of parents, not just model instances
  • Now using global datastore's delete, put, and get methods instead of model's

See the original announcement for a screencast and general information on Gaebar.

Please do keep your feedback coming and, of course, if you have pull requests, patches, or suggestions, please send them my way (and thank you!)

The Yahoo! Flex Skin is a lovely minimalist skin by the good folks on Yahoo!'s Flash team. However, it has an issue that you need to work around if you want to load it in dynamically at runtime. It's a simple thing, but I thought I'd document it here in hopes that it will help save someone else a few minutes of confusion.

To switch to a different skin at runtime in Flex, you use StyleManager. loadStyleDeclarations, which takes a reference to a CSS file compiled into a SWF as its first (and only required) argument. When you look at the source for the Yahoo! Flex Skin, you might be fooled into thinking that the compiled SWF has been supplied for you since there are two files, yflexskin.css and yflexskin.swf in the folder.

yflexskin.swf, however, is the SWF that contains the assets referenced in the CSS file.

Since there is already a SWF file with the same name as the CSS file in the folder, Flex does not/can not compile the CSS file (as it would overwrite the existing SWF). This leads to a runtime error complaining that the SWF file cannot be loaded:

Error: Unable to load style(SWF is not a loadable module)

Here's the workaround:

1. Rename the asset SWF to something else, like yflexskinassets.swf.
2. Do a find and replace in yflexskin.css to rename yflexskin.swf to yflexskinassets.swf
3. In Flex Builder, right-click yflexskin.css and select Compile CSS to SWF

Now, when you want to switch to it at runtime, you can simply:

StyleManager.loadStyleDeclarations( "yflexskin/yflexskin.swf");

Simple, but may not be initially obvious. Hope this helps!