Today I am happy to announce that the public beta of FlairLoc is available.

Features

• Change resources in a user interface with search capability
• Extract resource keys from source code and synchronizes it with all locale sets
• Automatic translation into 42 languages with the Google Translate API
• Add new automatic translated languages in only 4 CLICKS
• Generation of locale compile statement and Ant parameters

For more information, screenvideo and screenshots and to install the application please visit the product page.

This release makes Swiz faster, more flexible and even easier to use:

• Support for mediating bubbled event
• Added view attribute in Mediate tag
• Autowire views with view attribute in Autowire tag
• Ignoring view classes with underscore for performance optimization
• Added viewPackages for performance optimization
• Added eventPackages for shorter notation in strict mode
• SwizConfig for Swiz MXML declaration
• Generic fault handler for executeServiceCall
• Autowire bean properties with new property attribute
• Prototype supports class reference and constructor arguments

Swiz got a new member Ben Clinkinbeard who contributed some really cool stuff which makes mediating events more flexible and removed the Swiz dependency from the view because they can now bubble and lot’s of other stuff. Awesome to have Ben on board!

So here a quick overview for each new feature/improvement:

Support for mediating bubbled event

Events don’t have to be dispatched with the central event dispatcher anymore. So when you have a view instead of:

Swiz.dispatchEvent(new FooEvent(FooEvent.CHANGE))

you can do:

dispatchEvent(new FooEvent(FooEvent.CHANGE))

When you want to use this approach you have to

• enable the feature with Swiz.setMediateBubbledEvents(true) or via SwizConfig
• set the bubble flag of the event to “true”
• override clone method of the event

So the view has no Swiz import statement anymore and in fact doesn’t know anything about Swiz except to autowire models.

Added view attribute in Mediate tag

A dynamic mediator can now listen for view specific events. In the following example the dynamic mediator only listens for events dispatches by the view class “MyView”:

[Mediate(event="SomEvent.FOO", view="MyView")]

This is also extremely helpful to code more generic itemRenderers.

Autowire views with view attribute in Autowire tag

You can now autowire views into any bean with:

[Autowire(view="true")]
public function set myView(view:MyView):void
{...}

The setter is invoked when the view is added to the stage and has fired its creationComplete event so you can access all members of the view which in MXML are all public scope.
For more details and an example read my post here.

Ignoring view classes with underscore for performance optimization

This is an internal performance optimization where you as a developer don’t have to change anything except you have view classes with an underscore in the classname.
In Swiz 0.6 view classes with “_” are ignored for dependency injection because these are internal classes like skin classes, cursors or internal non-custom item renderers. Because these kind of classes won’t contain any metadata we can safely ignore them which improves the runtime performance significantly.

Added viewPackages for performance optimization

For further optimization beyond already ignoring underscore classes you can now define one or multiple view packages. If you set this property only views in these packages will get autowired.
You can set the viewPackage with

Swiz.addViewPackage("com.domain.project.view")

or with the new SwizConfig.

Added eventPackages for shorter notation in strict mode

When you are using Swiz in strict mode you can now define eventPackages to have a shorter notation of the event. I already blogged about this feature here.

SwizConfig for Swiz MXML declaration

Instead of adding an event listener for the Application/WindowedApplication preInitialize event and the calling Swiz.loadBeans besides configuring Swiz you can now use the new SwizConfig class in MXML. The markup for an AIR app then looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
 
	<mx:Script>
		<![CDATA[
			import mx.rpc.events.FaultEvent;
			import mx.logging.LogEventLevel;
 
			private function genericFault(fe:FaultEvent):void
			{
				// TODO handle fault
			}
 
		]]>
	</mx:Script>
 
	<mx:TraceTarget fieldSeparator="->" includeLevel="true" includeCategory="true" includeTime="true" />
 
	<swizframework:SwizConfig xmlns:swizframework="org.swizframework.*"
		strict="true"
		mediateBubbledEvents="true"
		eventPackages="example.event"
		viewPackages="example.view"
		beanLoaders="{[Beans]}"
		serviceCallFaultHandler="{genericFault}"
		logEventLevel="{LogEventLevel.WARN}"
		/>
 
	<view:SwizConfigTestView xmlns:view="example.view.*" width="100%" height="100%" />
 
</mx:WindowedApplication>

The SwizConfig itself will listen for the preInitialize event of the application and configure Swiz.

Generic fault handler for executeServiceCall

When you use Swiz.executeServiceCall or subclass AbstractController and call executeService call you can leave out the fault handler. When a fault comes up Swiz currently shows an Alert window with the fault details. You can override this like in the SwizConfig example above.

Autowire bean properties with new property attribute

You can now autowire bean members instead of the bean itself. So instead of:

[Bindable][Autowire]
public var someModel:SomeModel;
 
<mx:List dataProvider="{someModel.someList}" />

you can use:

[Bindable][Autowire(bean="someModel", property="someList")]
public var someList:ICollectionView;
 
<mx:List dataProvider="{someList}" />

Prototype supports class reference and constructor arguments

Prototype (see old post here) now support constructor arguments and you can declare a class reference instead of the full qualified class name.
Example:

<factory:Prototype xmlns:factory="org.swizframework.factory.*"
	classReference="{SomeClass}" constructorArguments="{['foo', 'bar']}" />

There will come a lot of new blog posts regarding each new feature soon but I hope this has given an overview about what’s new in 0.6. Besides that we try to add more documentation and example projects.

In Cairngorm you have a few central classes which are accessible as singletons. In Swiz you won’t have any singletons in your code at all if you don’t want to but instead you will use the Autowire annotation to let Swiz wire things together for you using dependency injection aka Inversion of Control. These kind of classes are mainly models, controllers, delegates and services.

You can mix Cairngorm and Swiz at the same time while migrating so you are not forced to refactor your application at once but in an iterative way.

Let’s get started: Download the latest Swiz library SWC and add it to your project libs. If you want to check out the latest sources from SVN to compile the SWC on your own be sure to add the compiler parameter -keep-as3-metadata+=Autowire,Mediate.

To initialize Swiz you need at least one BeanLoader which will be the place where you declare models, controllers, delegates and services. The terminology “Bean” will probably change in one of the next Swiz releases. Imagine the BeanLoader as the place where you set up non-view classes.

Create a new MXML class and call it e.g. MyLoader and let it extend BeanLoader. Then change the namespace to org.swizframework.util.* so it will look like this:

<?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*">
 
</BeanLoader>

So let’s refactor your first peace of code. Let’s assume your ModelLocator contains a class ContactModel which holds a list of contacts. The ContactModel instance is bound to one of your views like:

[Bindable]
var modelLocator:MyModelLocator = MyModelLocator.getIntance();
 
<mx:List dataProvider="{modelLocator.contactModel.list}" />

Now remove the contactModel from your ModelLocator and add it to the BeanLoader so it will looks like this:

<?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*">
	<model:ContactModel xmlns:model="com.domain.project.model.*" />
</BeanLoader>

and change the view to this:

[Bindable][Autowire]
public var contactModel:ContactModel;
 
<mx:List dataProvider="{contactModel.list}" />

With the Autowire annotation we tell Swiz that we need the the ContactModel. It has to be defined public because otherwise Swiz is not able to inject the instance defined in MyLoader.
Now we have to tell Swiz to use the MyLoader where we have just set up our ContactModel. Switch to your main application MXML and add an event listener for preinitialize and define the event handler like this:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	preinitialize="preInitHandler()" />
	<mx:Script>
		<![CDATA[
			import org.swizframework.Swiz;
			import com.domain.project.MyBeans;
			private function preInitHandler():void
			{
				Swiz.loadBeans([MyBeans]);
			}
		]]>
	</mx:Script>

You see that loadBeans expects an array so you can define multiple BeanLoaders if you like.
In this case we have used autowire-by-type. This means Swiz will find the ContactModel because only one instance is defined in the BeanLoader. If you have classes of the same type in the BeanLoader you can also autowire by id. Only give the instance an id like e.g. id=”contactModel” and autowire it with [Autowire(bean="contactModel")]

With this refactoring we might have broken a Cairngorm command because now the flow looks like this

• Command was invoked from a Cairngorm event mapped to in the FrontController
• Command instantiated a Business Delegate and added itself as a Responder implementing the Responder interface
• Business Delegate gets service from ServiceLocator and calls it
• Service returns result/fault and the Command in this case Responder gets notified

With Swiz you have no FrontController, no ServiceLocator and the delegates are also only created once because they live in a BeanLoader. The Command will be replaced by a controller so it is easier to have multiple actions in one controller so you don’t end up with a ContactReadCommand, ContactAddCommand, ContactUpdateCommand or a switch statement in the command itself to determine which event came in.

To refactor do the following:

• Move the contact service from ServiceLocator to MyLoader
• Add the delegate to MyLoader
• Create a new controller called ContactController extending AbstractController and add it to MyLoader

Your BeanLoader now looks smilar like this:

<?xml version="1.0" encoding="utf-8"?>
<BeanLoader xmlns="org.swizframework.util.*"
	xmlns:mx="http://www.adobe.com/2006/mxml"
	xmlns:model="example.model.*"
	xmlns:ctrl="example.ctrl.*"
	xmlns:business="example.business.*">
 
	<model:ContactsModel />
	<ctrl:ContactController />
	<business:ContactDelegate />
	<mx:HTTPService id="contactService" />
 
</BeanLoader>

It is best practice to let delegates implement an interface so other classes only have to deal with a clean interface so the ContactDelegate interface looks like this:

package example.business
{
	import mx.rpc.AsyncToken;
 
	public interface IContactDelegate
	{
		function getContacts():AsyncToken;
	}
}

and the implementation like this:

package example.business
{
	import mx.rpc.AsyncToken;
	import mx.rpc.http.HTTPService;
 
	public class ContactDelegate implements IContactDelegate
	{
 
		[Autowire(bean="contactService")]
		public var service:HTTPService;
 
		public function getContacts():AsyncToken
		{
			return service.send();
		}
 
	}
}

You see that we simply autowire the service instead of having any call to a ServiceLocator.

Now the controller. The ContactController has two dependecies. We will need access to the delegate to call the service and to the model to store the result and both will be autowired:

package example.ctrl
{
	import example.business.IContactDelegate;
	import example.model.ContactModel;
 
	import mx.collections.ArrayCollection;
	import mx.rpc.AsyncToken;
	import mx.rpc.events.ResultEvent;
 
	import org.swizframework.controller.AbstractController;
 
	public class ContactController extends AbstractController
	{
 
		[Autowire]
		public var model:ContactModel;
 
		[Autowire]
		public var delegate:IContactDelegate;
 
		public function ContactController()
		{
		}
 
		[Mediate(event="loadContacts")]
		public function loadContacts():void
		{
			var call:AsyncToken = delegate.getContacts();
			executeServiceCall(call, contactsResultHandler);
		}
 
		protected function contactsResultHandler(re:ResultEvent):void
		{
			var ac:ArrayCollection = re.result as ArrayCollection;
			model.list = ac;
		}
 
	}
}

You see something new which is the Mediate annotation [Mediate(event="loadContacts")]
Instead of a FrontController which maps events to commands Swiz uses a concept called dynamic mediators. In this case we are using a primitive event and there are more sophisticated ways to implement dynamic mediators and also pass parameters (event member variables) etc.

So let’s say you want to load the contacts when your application starts simply add this line of code to the main application creationComplete event handler:

Swiz.dispatch("loadContacts")

Swiz is aware of all mediate annotations and has created event listeners and with the line above our controller method loadContacts gets invoked. You could also use an event class which does not need a special base class like the CairngormEvent but only flash.events.Event. For more info and some shortcuts and runtime validation read on here about eventPackages.

So let’s some up how the different layers of your application work together:

• Declare models, controller, delegates and services in the BeanLoader and load them with Swiz.loadBeans
• Views get the model autowired and can add data bindings.
• Views dispatch events caused by user gestures with Swiz.dispatchEvent or Swiz.dispatch
• Controller mediate events with [Mediate(event="...", properties="...")]
• Controllers get models autowired which need to be changed by the controller.
• If the controller calls a service autowire the delegate
• Delegates autowire services and return the AsyncToken from the service call

I hope at this post you have learned some concepts of Swiz compared to Cairngorm and see that migrating from Cairngorm to Swiz means more decoupling and removing repetitive code. I had a large project with more than one year development spend on and refactoring was done in a short timeframe and reduced about 30% lines of code.

If you have more questions please drop a comment and/or join the mailing list.