Brian Kotek: Inversion of Control - Swiz

Swiz Example Application Demonstrating Module Support

Mon, 16 Aug 2010 13:12:00 -0700

I just pushed a new sample application called SwizModuleExample-Flex4 to GitHub. This example is meant to demonstrate the various ways that Swiz supports the use of modules. The key ideas demonstrated are:

Loading a Module
Detecting full creation of a Module (not just the ModuleEvent.READY event)
Dispatching events from a root Swiz instance that are mediated by all Modules
Dispatching events from a root Swiz instance to a specific Module
Dispatching events from a Module that are mediated in the root Swiz instance
Dispatching events from a Module that are mediated by other Modules.
Injecting Beans that are defined in a root Swiz instance into a child Swiz instance.

While this example is really meant to be looked through at the code level, I have a running version with View Source enabled that you can look at as well. I hope folks find this example helpful!

CFUnited Clean Code and Swiz Presentations Now Online

Wed, 04 Aug 2010 15:33:00 -0700

Just a quick note that, as promised, my presentations from CFUnited are now online! Clean Code The Swiz Framework for Flex and ActionScript Thanks to all who attended!

Using the Swiz AutowiredTestCase

Tue, 15 Jun 2010 09:27:00 -0700

One of the utility classes that is part of the Swiz library is AutowiredTestCase. As the name implies, you can use this class to help test your Swiz applications. In this case, code will show what's going on much better than doing a lot of typing, so here is a sample FlexUnit 4 test case. First, the class under test:

js|
package com.briankotek.flex4swiztests.control
{
	import com.briankotek.flex4swiztests.event.MyEvent;
	import flash.events.IEventDispatcher;

	public class MyController
	{
		
		[Dispatcher]
		public var dispatcher : IEventDispatcher;
		
		public var didSomething : Boolean = false;
		
		[Mediate( event="MyEvent.CONTROLLER_ACTION_REQUESTED" )]
		public function handleAction() : void
		{
			didSomething = true;
			actionComplete();
		}
		
		private function actionComplete() : void
		{
			dispatcher.dispatchEvent( new MyEvent( MyEvent.CONTROLLER_ACTION_COMPLETE ) );
		}
		
	}
}

You can see this is a simple controller, which responds to the CONTROLLER_ACTION_REQUESTED event, updates a property, and then dispatches CONTROLLER_ACTION_COMPLETE. We want to test that the controller is responding to the correct event, property updating the property, and finally dispatching the completion event. The event itself is a simple event class:

js|
package com.briankotek.flex4swiztests.event
{
	import flash.events.Event;
	
	public class MyEvent extends Event
	{
		public static const CONTROLLER_ACTION_REQUESTED : String = "controllerActionRequested";
		public static const CONTROLLER_ACTION_COMPLETE : String = "controllerActionComplete";
		
		public function MyEvent(type:String)
		{
			super(type, true, false);
		}
	}
}

Finally, the test case itself:

js|
package com.briankotek.flex4swiztests.control
{
	import com.briankotek.flex4swiztests.control.MyController;
	import com.briankotek.flex4swiztests.event.MyEvent;
	import org.flexunit.Assert;
	import org.flexunit.async.Async;
	import org.swizframework.core.*;
	import org.swizframework.utils.test.AutowiredTestCase;

	public class MyControllerTestCase extends AutowiredTestCase
	{	
		private var myController : MyController;
		
		[Before]
		public function setUp():void
		{
			myController = new MyController();
			
			swizConfig = new SwizConfig();
			swizConfig.eventPackages = "com.briankotek.flex4swiztests.event.*";
			
			beanProviders = [new BeanProvider( [myController] )];
		}
		
		[After]
		public function tearDown():void
		{
			myController = null;
		}
		
		[Test(async)]
		public function testControllerActionRequested() : void
		{
			Assert.assertTrue( "Controller property is already true.", myController.didSomething == false );	
			Async.handleEvent( this, swiz.dispatcher, MyEvent.CONTROLLER_ACTION_COMPLETE, checkEvent ); 
			swiz.dispatcher.dispatchEvent( new MyEvent( MyEvent.CONTROLLER_ACTION_REQUESTED ) );
		}
		
		private function checkEvent( event : Event, passThroughData : Object ) : void
		{
			Assert.assertTrue( "Controller property was not updated.", myController.didSomething == true );	
		}
		
	}
}

I start off setting up an instance of Swiz that my test can use. AutowiredTestCase has a method marked with [Before] metadata, so that FlexUnit runs it before each test. I create an instance of the class under test (MyController), then set the event packages on the SwizConfig. Finally, I place the MyController instance into a BeanProvider, so that Swiz will process it as a bean. This way, any Swiz metadata in MyController is processed. The test method dispatches a CONTROLLER_ACTION_REQUESTED event. If all goes well, the mediated event in the controller should run, update the property, and then the controller will dispatch the completion event. Running the test produces a passing result, so everything is working as expected! Note that because Swiz actually processes your test case itself as a bean, you can use Swiz metadata in your test if you want or need to. So injecting a dispatcher, mediating an event, or testing custom metadata processors are all possible as well.

Swiz 1.0RC Released! So here's an updated example, custom ViewMediator, and more

Wed, 19 May 2010 09:56:00 -0700

There's a lot of good news from the Swiz world today. First, we just released the Swiz 1.0 Release Candidate, which fixes a number of small bugs in the beta and adds numerous new features. This version should be pretty much feature-complete, so at this point we'll be focused on fixing any issues that come up. A final 1.0 should be out in the next few weeks. I did my best to help out with this release by working hard on updated documentation. You can see the fruits of this labor on the new Swiz documentation wiki we've created through JIRA Studio. You can also sign up to enter feature requests or bugs, vote on issues, and all the other good stuff that JIRA provides. If you have any feedback on the documentation, feel free to leave a wiki comment and we'll do our best to address it. I've also created a Swiz 1.0RC version of my example application. If you like, you can view or download the source code. Since 1.0RC removes the option for "view injection" into a bean, folks have asked about ways to handle providing a view to a Swiz bean. I created a MediateView custom metadata extension that should handle most of these needs. I'll do my best to keep it up to date as I get feedback about it. And finally, in the "better late than never" department, I've uploaded the Swiz presentation I gave at cf.Objective() 2010 to SlideSix. I'll also be speaking on Swiz at this year's CFUnited conference. If you're planning on going, I'm happy to talk about Swiz into the wee hours of the morning!

Swiz Example Application Updated to Support Swiz 1.0 Beta

Fri, 05 Mar 2010 08:59:00 -0700

Update on 8/16/10: With the release of Swiz RC1, I released an updated version of this example application. With the release of the 1.0 Beta of the Swiz framework, I've updated my Swiz example application to the latest version. You can also view the source code if you like. I'd like to point out a few things that I had to change from the example based on version 0.6.4:

The instantiation of the framework has changed in order to support multiple instances of Swiz, primarily for Flex module support:
xml|
The static methods on the Swiz class have been removed, due to the fact that there can now be multiple instances of Swiz. This means that instead of doing something like Swiz.dispatchEvent( event ), you now want to inject a dispatcher object into your non-view objects and dispatch events through it instead. The two main ways to do this are to inject the dispatcher in your BeanLoader/BeanProvider, or by having your class implement the IDispatcherAware interface, which will instruct Swiz to inject the dispatcher automatically.
The [Autowire] metadata tag has been deprecated in favor of the more industry-standard [Inject]. [Autowire] will still work for now, but be aware that this may be removed in a future release.
The use of the earlier CommandChain has changed to support more robust and extensible chains, as well as supporting internal Flex event-based chains on top of the existing support for chains that make server calls. For example:
js| var chain : CommandChain = new CommandChain(); chain.addMember( new AsyncChainStepCommand( delegate.deleteUser, [user], userDeleteHandler ) ); chain.addMember( new AsyncChainStepCommand( delegate.deleteUserProfileImage, [user], userProfileImageDeleteHandler ) ); chain.addEventListener( "chainComplete", userDeleteCompleteHandler, false, 0, true ); chain.start();

Anyway, that's all for now, but I'll be posting more about the Swiz updates soon. If you're interested in seeing more about 1.0, have a look at Sam Ahn's demo of Swiz using AS3Signals. A very cool use of the brand new custom metadata support now available in Swiz!

Swiz 1.0 Beta is Live!

Mon, 01 Mar 2010 11:29:00 -0700

This morning, the Swiz team released the 1.0 Beta of the Swiz Framework. You can view the extensive list of updates at the Swiz web site. Have a look and try out the new features. We'll be doing a full update of the documentation as we prepare for the final release. I also have an updated version of my sample application about ready, and I will upload it and highlight the differences between 0.6.4 and 1.0. Stay tuned!

My CFinNC Presentations at SlideSix

Thu, 22 Oct 2009 12:02:00 -0700

I've uploaded my CFinNC presentations to SlideSix for anyone who's interested: Object-Oriented Design Principles Introduction to Swiz Overall, CFinNC was great. I actually had to work for a large chunk of the weekend so aside from presenting and mingling with folks later in the evening, I didn't get to attend many other sessions. That said, everything looked top-notch while I was there. The conference unfolded very smoothly and all of the attendees seemed very engaged. Hats off to Dan Wilson and the entire volunteer team for pulling this off! This conference definitely held its own against the other CF conferences I've attended. It was very difficult to tell that it was completely free. Hopefully we can do it again next year!

I'm Speaking at the CFinNC Conference...See You There?

Fri, 04 Sep 2009 12:00:00 -0700

Just a quick note that I'll be speaking at the CFinNC conference on October 17-18th here in Raleigh, NC. My topics are Object-oriented Design Principles and The Swiz Framework for Flex. The conference is FREE and the lineup is very impressive, so if you can attend, please register! And if you register, please actually show up! The danger with a free conference is that it's easy for folks to back out at the last minute, since they lose nothing. But for the organizers, it makes estimating actual attendance difficult. So if you sign up, please do your best to make it. :-) I'm looking forward to seeing some folks that I normally have to wait until MAX or next year's CFObjective or CFUnited conferences to see. And I hope to meet a lot of new people as well. See you in Raleigh!

Swiz Part 5: Simulating Server Calls with a mock AsyncToken

Mon, 16 Mar 2009 13:16:00 -0700

In the last entry in this series on the Swiz framework, I discussed the use Dynamic Responders to make calls to the server as easy as possible. This entry is a short aside on how you can use some nice testing features that are built into Swiz to simulate calls to a server. As before, the current version of the application and its source code is available.

So far, we've looked at how Swiz's inversion of control (IoC) features make managing dependencies in a Flex application dead simple. We've dispatched events from the CentralDispatcher, and we've executed service calls using our Delegate class. But what is actually happening at the Delegate level? Let's delve into this.

You might have noticed that within my Controller, I'm having Swiz wire in an object of type IUserDelegate:

js|
[Autowire]
public var delegate : IUserDelegate;

Why am I specifying the type as an interface instead of an actual class name? Flexibility! One of the most basic tenants of object-oriented design is to "design to interfaces". That doesn't necessarily mean you have to type everything as an interface. It just means you should keep your typing at the highest level of abstraction that you can. Ideally, that means typing things to interfaces or abstract classes. Because I'm typing the delegate to IUserDelegate, that means I can have Swiz autowire anything that implements the contract defined by the IUserDelegate interface. And that's exactly what I'm doing. Here's the Beans.mxml file again:

xml|

You can see that the delegate is actually a MockUserDelegate. Here's the code for that class:

js|
package com.briankotek.swizdemo.delegate
{
	import com.briankotek.swizdemo.model.User;
	import mx.collections.ArrayCollection;
	import mx.rpc.AsyncToken;
	import org.swizframework.delegate.AbstractDelegate;
	import org.swizframework.util.TestUtil;

	public class MockUserDelegate extends AbstractDelegate implements IUserDelegate
	{
		
		// CONSTRUCTOR
		
		public function MockUserDelegate()
		{
			super();
		}
		
		// PUBLIC METHODS
		
		/**
		 * In a real application this would execute a server call to a remote object
		 */ 
		public function loadUsers() : AsyncToken
		{	
			return TestUtil.mockResult( buildMockUserCollection() );
		}
		
		/**
		 * In a real application this would execute a server call to a remote object
		 */ 
		public function saveUser( user : User ) : AsyncToken
		{
			if( !user.id )
			{
				user.id = Math.round( Math.random() * 100 );
			}
			return TestUtil.mockResult( user );
		}
		
		/**
		 * In a real application this would execute a server call to a remote object
		 */ 
		public function deleteUser( user : User ) : AsyncToken
		{
			return TestUtil.mockResult( user );
		}
		
		/**
		 * In a real application this might execute a call to a third party file server
		 */ 
		public function deleteUserProfileImage( user : User ) : AsyncToken
		{
			// Pretend that this deletes a file from a file server like Amazon S3.
			return TestUtil.mockResult( user ); 
		}

		// PRIVATE METHODS
		
		/**
		 * Build a fake collection of Users as a mock result.
		 */ 
		private function buildMockUserCollection() : ArrayCollection
		{
			var result : ArrayCollection = new ArrayCollection();
			
			var user1 : User = new User();
			user1.id = 1;
			user1.firstName = "Tom";
			user1.lastName = "Swift";
			result.addItem( user1 );
			
			var user2 : User = new User();
			user2.id = 2;
			user2.firstName = "Bob";
			user2.lastName = "Hope";
			result.addItem( user2 );
			
			var user3 : User = new User();
			user3.id = 3;
			user3.firstName = "Alan";
			user3.lastName = "Alda";
			result.addItem( user3 );
			
			var user4 : User = new User();
			user4.id = 4;
			user4.firstName = "Roger";
			user4.lastName = "York";
			result.addItem( user4 );
			
			return result;	
		}
	}
}

As you can see, I'm not actually making a call to a server. I'm generating an ArrayCollection of "fake" User objects, and then using a handy method called mockResult() in the Swiz TestUtils class. This method generates an AsyncToken for you and adds your result to it. It will even let you simulate a delay, like a real server call would have. In this way, you can easily test your Swiz application without needing the server side working. This not only makes examples like mine much easier to release, but it lets you unit test your applications, as well as do work on parts of the UI before the server-side code has been implemented yet. I hope you can see the usefulness of this approach, the handy nature of Swiz's mockResult() method, and the ease with which Swiz lets you swap out implementations like this. I'll sign off for now, but in the next entry (which will come more quickly than this one did, I promise) we'll look at another great Swiz feature: Dynamic Event Mediators.

Swiz Part 4: Dynamic Responders

Mon, 09 Feb 2009 09:39:00 -0700

In the last entry in this series on the Swiz framework, we looked at how the CentralDispatcher can make dealing with events a lot easier. Now I'd like to take a look at how Swiz makes interacting with an application server just as simple. Once again, the current version of the application and it's source code is available. [More]

Using Swiz Part 3: Events

Fri, 23 Jan 2009 09:42:00 -0700

In the last installment, we saw how Swiz can help you by resolving dependencies between your ActionScript classes and MXML components. But I left you with a very simple example, hardly more than a "Hello World". In this entry, I'd like to start digging into a more "real world" use of Swiz. Based on some comments I've gotten on and off the blog, I'm uploading an interim version of the application with view source enabled. You can see it at http://www.briankotek.com/examples/swizdemo_events/Main.html. Keep in mind that in order to get it to a runnable state, the code contains a good number of things that I haven't talked about yet. Look around if you like, but for now don't pay too much attention to something if you aren't sure what it's doing yet. I'll get to it all, I promise! :-) (A small note, right now there is an issue with the "fake" server calls that can cause the busy cursor to remain on screen. I believe this is a small issue with the test utility included in the Swiz library, and I'm going to mention it to Chris. For now, just ignore it heh). Judging by questions on the Swiz discussion list, many people are a bit unsure of when things happen and when you are cleared to actually work with the beans that Swiz manages for you. If you run a Swiz application in debug mode, you should see some trace statements in the console that note several steps in the process. However, keep in mind that Swiz must create your objects first, and then autowire them. Which means that the dependent classes will not be available when your object is created, and references to dependent objects in your constructor will cause an error since the dependency hasn't been set yet. The same is true for views, in that view components are not autowired until they are added to the stage, which is occurs near the end of the component lifecycle. It happens after creationComplete, which means you are not safe referencing dependencies in that event handler. Further, because of the fact that Flex events like creationComplete execute in sequence from the innermost child up through the display list hierarchy to the root container (the Stage), you must exercise even more care. (And that is a general issue for Flex development, not really specific to Swiz). I've found that the easiest way to deal with issues like these is to minimize reliance on creationComplete, as well as minimizing situations where you try to pass data into a visual component from a parent. For example, consider:

It might look OK on the surface, but we can run into issues if the UserContainer component does something like this in it's creationComplete handler:

js|
private function creationCompleteHandler() : void
{
    if( users.length > 0 )
    {
        // do something
    }
}

You see the problem? When UserContainer's creationCompleteHandler runs, it's parent hasn't had the controller autowired into it yet! Which means the reference to users in the UserContainer will be null. In fact, the parent hasn't even had the controller autowired into it yet. As an aside, some of the most difficult initial mental obstacles I faced when starting with Flex was this issue of creation timing. It can get pretty nasty when you have several levels of components, each depending on something provided by their parent. But I digress. Basically I've found it best to let the application set itself up and THEN dispatch an event that begins populating things with data. And this is where I can also introduce the Swiz CentralDispatcher. In my user manager application, I need SOMETHING to set off processing that gets the list of users and displays it in the data grid. I used a simple approach like this in my Main.mxml file:

js|
private function applicationCompleteHandler( event : Event ) : void
{
	Swiz.dispatchEvent( new Event( UserController.APPLICATION_LOAD_REQUESTED ) );
}

So once this event fires, that means all of the child components have been created, added to the stage, and had any Swiz beans autowired in. At this point, I know the application is in a state where everything is ready to go. Right away, you may notice the first advantage of Swiz's event dispatching mechanism: it doesn't require custom or framework-specific Events. Frameworks like Cairngorm demand that you use their "special" Event objects. Not so with Flex. You can use custom Event types if you like, or you can use standard Flex events. It's one less framework dependency. Note that Swiz makes using it's event dispatching mechanism as simple as possible by providing static methods on the Swiz class to handle listening for and dispatching events. It's just one more nice convenience that Chris had the foresight to add. The benefit of using a central dispatcher like the one Swiz provides is to get around an issue with the way Flex normally dispatches events: they only "bubble UP" the component hierarchy. There's no easy way to get CHILD components to respond to an event that is dispatched by a parent. By dispatching events through the central dispatcher, any class can listen for events of interest, regardless of where they sit in the hierarchy. If you look at the controller code that handles this APPLICATION_LOAD_REQUESTED event, it's a standard event listener and corresponding handler. The only difference of note is that the listener is configured on the Swiz central dispatcher:

js|
public function UserController()
{
	super();
	users = new UserListCollection();
	Swiz.addEventListener( APPLICATION_LOAD_REQUESTED, loadUsers );
}

public function loadUsers( event : Event ) : void
{
	executeServiceCall( delegate.loadUsers(), userLoadHandler );
}

Ignore the "executeServiceCall()" method for now, we'll get to that in the next entry. The point is: from here, my application kicks off the process of getting the user list and then providing it to the view. If you look at the attached code, you can see that the Swiz central dispatcher is also used to move data into the view. That's all for now. In the next entry, I'll look at how Swiz makes getting data from the server just as easy.

Using Swiz Part 2: Dependency Injection

Wed, 14 Jan 2009 11:15:00 -0700

In my last entry, I showed how to get a Flex application up and running using the Swiz framework. In this post, I'm going to take a look at what is probably Swiz's killer feature: dependency injection. Folks familiar with Spring or ColdSpring will recognize the term, but in case you don't, let me quote from Wikipedia:

Conventionally, if an object needs to gain access to a particular service, the object takes responsibility to get hold of that service: either it holds a direct reference to the location of that service, or it goes to a known service locator and requests that it be passed back a reference to an implementation of a specified type of service. By contrast, using dependency injection, the object simply provides a property that can hold a reference to that type of service; and when the object is created a reference to an implementation of that type of service will automatically be injected into that property by an external mechanism.

If that's a little too technical for anyone, I'll translate a bit. The idea is to use some external process to look at the dependencies between your objects, create them in the proper order, and then supply the necessary objects to each other. Consider how you might be creating objects right now. You could be doing something like this in your Main.mxml file or some kind of configuration object:

js|
var xmlUtils = new XMLUtils();
var contentDelegate = new ContentDelegate();
contentDelegate.xmlUtils = xmlUtils;
var securityController = new SecurityController();
securityController.xmlUtils = xmlUtils;
var contentController = new ContentController();
contentController.securityController = securityController;
contentController.contentDelegate = contentDelegate;

So ContentController needs instances of SecurityController and ContentDelegate, which in turn both need an instance of XMLUtils. Kind of nasty, and we're only dealing with four objects. Now think about what that would look like for 40 objects. Or 400. Yikes. Wouldn't something like this be nicer? Imagine this within the ContentController:

js|
[Autowire]
public var securityController : SecurityController;

[Autowire]
public var contentDelegate : ContentDelegate;

This is exactly what Swiz will do. Once you initialize the framework and supply a set of bean definitions (which I did in my last blog entry), Swiz will automatically create those components and resolve all of their dependencies. Which, if you think about it, is pretty killer. But it doesn't stop there. In addition to autowiring Singleton components like controllers and delegates, it will also autowire your views! Yes, it's true. If you have a view containing properties with [Autowire] metadata, Swiz will inject the proper beans into your view as soon as it is added to the stage. Which sweeps away all sorts of issues (or at least issues that I had run into before) related to the creation order of display objects. A few additional notes about autowiring. In the examples above, I'm using what is called "autowire by type". This means that Swiz looks at the property's type and then looks for a bean that it is managing with the same type. It even works with interfaces and supertypes, which is very useful. Autowire by type is fine for most situations, but if you can't rely on the type alone (such as having Swiz manage multiple different beans of the same type), you can also specify the bean ID if you need to:

js|
[Autowire( bean="userController" )]
public var userController : UserController;

Another handy feature is that you can autowire properties that are declared using implicit setters as well. This means that you can execute additional logic when the bean is autowired:

js|
[Autowire]
public function set userController( userController : UserController ) : void
{
	_userController = userController;
	// Run some additional code after the userController is set.
}
public function get userController() : UserController
{
	return _userController;
}
private var _userController : UserController;

There are a few other cool features related to autowiring and the process Swiz goes through to resolve the dependencies and create the beans, but I don't want to veer too far off into the low level details. Let's return to the little user manager application that I prototyped in the previous entry. With these ideas about autowiring in mind, lets see how we can apply them to this application. I don't have much in the way of dependencies because there are only a small number of classes, but my Beans.mxml file looks like this:

So Swiz is managing two beans for me, a User controller and a User delegate. I want the delegate wired into the controller, so my controller will start off like:

js|
package com.briankotek.swizdemo.controller
{
	import com.briankotek.swizdemo.delegate.IUserDelegate;
	import org.swizframework.controller.AbstractController;

	public class UserController extends AbstractController
	{
	// PUBLIC PROPERTIES
	
	[Autowire]
	public var delegate : IUserDelegate;
	}
}

I'm specifying the delegate's type as an interface (IUserDelegate) so that I can swap implementations of the delegate if I want to, such as swapping the MockUserDelegate for a real UserDelegate later on. As long as they both implement the IUserDelegate interface, nothing outside of Swiz needs to know which one is actually being used. We'll look at this delegate in detail in an upcoming post. For now, let's just see this work. My Main.mxml file to test that the autowiring is working is:

Which reveals that the controller was indeed wired into my view correctly, as well as confirming that the delegate was wired into the controller correctly. And this was all done in an impressively small amount of code. Hopefully this gets your mind turning about the potential of dependency injection. Remember that this is a deliberately small example, but you can probably see how much of a benefit this would be in larger applications. That's all for today, but in the next entry, we'll move away from just running a simple test in the Main.mxml. On the whole, Flex apps don't really work like this. Flex is an event-driven framework, with code dispatching events to trigger the execution of additional logic. We'll see how Swiz facilitates this through it's central event dispatcher.

Using Swiz Part 1: Initial Setup

Thu, 08 Jan 2009 09:53:00 -0700

To begin this series on Swiz, I whipped up a couple of mockups using Balsamiq to show what the end result should be. It's going to be a pretty simple user manager interface. Let's have a quick look at those images and then we'll move on to setting up an application shell for this using Swiz. [More]

A New Series on Understanding and Using the Swiz Framework for Flex

Mon, 05 Jan 2009 09:56:00 -0700

As part of my commitment to blog more often in 2009, I'm starting an ongoing series on the Swiz framework for Flex. If you aren't aware, Swiz is the brianchild of Chris Scott, and may CF'ers will recognize him from this work on the ColdSpring framework. Being the brilliant guy that he is, he's taken many of the principles of Spring and ColdSpring and applied them to Flex development. The result is Swiz, and after doing work with Cairngorm, Swiz is like being paroled! It feels pretty nice to do things simply with Swiz that would have required large amounts of boilerplate code in Cairngorm. At Broadchoice, we chose Swiz as the framework to underpin our Workspace application. As a result, I've had a good amount of time to get familiar with Swiz and try out some of it's bleeding-edge features. What I'd like to do is share what I've learned about it, with two main goals: To explain how it is useful to folks not familiar with it (or even with Flex for that matter). And second, to try and get some discussion going among those already using Swiz to see if I can learn more from them, and vice versa. I've chosen to examine and work through a fairly simple (though non-trivial) Flex application that uses Swiz. Over the coming days and weeks I'll be blogging about various pieces of the application and what Swiz is doing. I figure it will end up being about 7 or 8 blog entries, but we'll see how it goes and what sort of comments and response I get. Just to create a starting point to work up from, here are some of the topics I plan to talk about. Each of these is incorporated in the sample application I'm building, so we'll do more than simply talk about these, we'll put them to use.

Getting a Swiz application running
Swiz dependency injection and autowiring
Using the Swiz Central Dispatcher for events
Dynamic Responders
Using the MockAsyncToken to simulate remote server requests
Dynamic Mediators
Dynamic Commands
The Fluint unit testing framework for Flex
Integrating Swiz into Fluint to ease testing

I have a few other ideas for topics that I may throw in or add as tangents, but let's see how this initial roadmap goes. I'll be working on the app as we go, so I'll primarily be posting code in the blog entries, and then at the end I'll push a finalized zip file of the application for folks to download and play with. The first entry will up in the next day or so. What do you folks think? Anyone out there ready to dig into Swiz with me?