Brian Kotek:
Inversion of Control

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:
  

  <swiz:SwizConfig id="mySwizConfig"
                   eventPackages="com.briankotek.swizdemo.event"
                   viewPackages="com.briankotek.swizdemo.view"
                   defaultFaultHandler="{genericFault}" />
  
  <swiz:Swiz id="mySwiz" beanProviders="{[Beans]}" config="{mySwizConfig}" />
  		

• 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:
  

  var chain : CommandChain = new CommandChain();<br>
  chain.addMember( new AsyncChainStepCommand( delegate.deleteUser, [user], userDeleteHandler ) );<br>
  chain.addMember( new AsyncChainStepCommand( delegate.deleteUserProfileImage, [user], userProfileImageDeleteHandler ) );<br>
  chain.addEventListener( "chainComplete", userDeleteCompleteHandler, false, 0, true );<br>
  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!

Comments (19) | del.icio.us | Digg It! | Linking Blogs | 630 Views

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!

Comments (0) | del.icio.us | Digg It! | Linking Blogs | 276 Views

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!

Comments (1) | del.icio.us | Digg It! | Linking Blogs | 983 Views

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!

Comments (0) | del.icio.us | Digg It! | Linking Blogs | 1100 Views

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:

[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 version="1.0" encoding="utf-8"?>
<BeanLoader 
	xmlns="org.swizframework.util.*" 
	xmlns:mx="http://www.adobe.com/2006/mxml"
	xmlns:controller="com.briankotek.swizdemo.controller.*"
	xmlns:business="com.briankotek.swizdemo.delegate.*">

	<controller:UserController id="userController" />
	<business:MockUserDelegate id="userDelegate" />

</BeanLoader>
		

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

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.

Comments (9) | del.icio.us | Digg It! | Linking Blogs | 3413 Views