To achieve this goal, I thought it would be interesting for the audience to look at the exact same application built with four different frameworks. And to avoid any misrepresentation of the frameworks, I asked the framework creators to build their own version of the application. Laura Arguello (Mate), Chris Scott (Swiz), Alex Uhlmann (Cairngorm), and Javier Julio (PureMVC, standing in for Cliff Hall) accepted to take part in the experiment and implemented their own version of the “framework-less” application I provided them with. (Many thanks to all of them for the time and energy they put in the project!)

The end result was a three hours session where each of them presented their version. The session format wasn’t perfect: Three hours was too short to get the attendees to actually build the application using four different frameworks, but it was probably also a little too long to look at and decipher code written by someone else. But in the end I think the information that was provided and the applications the attendees left with were really useful for anybody looking at making a framework decision.

Download

I thought these applications would also be helpful to you if you didn’t attend the session…You can download the code here and read the Getting Started instructions here.

Notes:

• The “plain” project is the framework-less version of the application.
• Do not unzip flex-frameworks-max.zip in a directory path that includes white spaces.
• You will notice that there may be different projects for a single framework. This is because there is sometimes a conflict between apparent simplicity and real abstraction, and I wanted to make sure the framework creators would be able to show different ways to use their framework.

What’s wrong with the plain version?

The implementation of the plain (framework-less) version is intentionally simplistic. Components are tightly coupled (for example, views are tightly coupled to specific types of services); the responsibility of components overlap (poor implementation of the “separation of concerns” concept); the configuration/initialization of components is not externalized; there is no clear messaging scheme in the application, which in turns leads to tight coupling, etc. These are some of the things to look at, when you examine a specific framework implementation of the application.

More Information

Laura posted her presentation here.
Javier posted his presentation here.

This is a 3 hour BYOL (Bring Your Own Laptop) session. The idea is to look at four versions of the exact same application: each version built with a different framework by a framework founder or expert: Laura Arguello for Mate, Chris Scott for Swiz, Javier Julio for PureMVC, and Alex Uhlmann for Cairngorm.

Each of them will have 45 minutes to walk you through the code and highlight the details of their implementation. The goal of the session is not to declare a winner, but rather to compare different solutions to the same problem, and for you to identify the framework that fits your application requirements and your style.

The session is described here in the Adobe MAX session catalog.

I hope to see you there. This should be a great session!

Parsley 2 was released too late to make the initial line up, but I’m trying to find a way to include a Parsley version of the application in the session materials as well.

Parsley is primarily a Dependency Injection framework. It also offers a very interesting messaging infrastructure. I won’t get into the details of dependency injection here: My previous Swiz and Spring ActionScript articles provide some background information, and there are also plenty of detailed resources out there.

If you just want to run the application and dive into the code, here are the links:

• Click here to run the application.
• Click here to view the source code.

Object Configuration

Parsley allows you to configure the core objects of your application (the objects other components depend on) in MXML (like Swiz), in XML (like Spring ActionScript), in ActionScript, or using any combination of these approaches. You can also extend the framework and create your own configuration mechanism.

For the inSync application, I used a simple MXML configuration (Config.mxml) defined as follows:

<?xml version="1.0" encoding="utf-8"?>
<Object xmlns="*" xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:services="insync.parsley.services.*">

    <mx:RemoteObject
            id="contactRO"
            destination="contacts"
            endpoint="http://localhost:8400/samples/messagebroker/amf"
            showBusyCursor="true" />

    <services:ContactService />

</Object>

Note: In a real life application, you would not want to hardcode the endpoints of your services in your source code. You could use the XML configuration option to configure your endpoints in a more “externalized” fashion. More on this topic here.

Framework Initialization

You initialize the Parsley framework using the ContextBuilder class corresponding to the configuration approach you chose. Here is the main application file for the inSync application. Parsley is initialized in the preinitialize event of the application.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:views="insync.parsley.views.*"
	paddingTop="0" paddingLeft="0" paddingRight="0" paddingBottom="0"
	preinitialize="FlexContextBuilder.build(Config)">

	<mx:Script>
		<![CDATA[
			import org.spicefactory.parsley.flex.FlexContextBuilder;
		]]>
	</mx:Script>

	<mx:Style source="styles.css" />

	<views:MainView />

</mx:Application>

Dependency Injection

Parsley supports constructor injection, method injection, and property injection (by type or by id).

In the following example (ContactForm.mxml), the framework will inject a specific implementation of the IContactService interface. In this case, the ContactService instance created in Config.mxml will be injected. This is an example of injection by type. Coding to the interface allows us to keep the view decoupled from a specific implementation of IContactService.

Note: Parsley doesn’t force you to use any specific design pattern. For simplicity in this sample application, I inject a service directly into the view. The use of an interface provides some level of decoupling, but you can of course use other patterns (like the Presentation Model) to achieve a greater level of abstraction. The Dependency Injection and Messaging infrastructure of Parsley will make the implementation of these patterns easier.

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
	addedToStage="dispatchEvent(new Event('configureIOC', true))">

	<mx:Script>
		<![CDATA[

		import insync.parsley.model.Contact;
		import insync.parsley.services.IContactService;

		[Inject]
		public var service:IContactService;

		[Bindable]
		public var contact:Contact;

		private function save():void
		{
			contact.firstName = firstName.text;
			contact.lastName = lastName.text;
			contact.email = email.text;
			service.save(contact);
		}

		private function remove():void
		{
			service.remove(contact);
		}

		]]>
	</mx:Script>

	<mx:Form>
		<mx:FormItem label="Id">
			<mx:TextInput text="{contact.id}" enabled="false"/>
		</mx:FormItem>
		<mx:FormItem label="First Name">
			<mx:TextInput id="firstName" text="{contact.firstName}"/>
		</mx:FormItem>
		<mx:FormItem label="Last Name">
			<mx:TextInput id="lastName" text="{contact.lastName}"/>
		</mx:FormItem>
		<mx:FormItem label="Email">
			<mx:TextInput id="email" text="{contact.email}"/>
		</mx:FormItem>
	</mx:Form>

	<mx:HBox left="12" bottom="12">
		<mx:Button label="Save" click="save()"/>
		<mx:Button label="Delete" click="remove()"/>
	</mx:HBox>

</mx:Canvas>

Note that in order to get its dependencies injected when it’s added to the stage, a view has to dispatch the “configureIOC” event.

Messaging

Parsley provides a generic Messaging infrastructure that allows you to exchange messages between objects in a decoupled, flexible, and easy-to-use manner:

• The event dispatcher and the event handler don’t know about each other.
• The event dispatcher and the event handler are decoupled from the framework: You dispatch events the Flex way.

Let’s look at the Search feature inSync as an example:

• The Toolbar class includes a simple TextInput that allows the user to specify a search criterion.
• The ContactList class displays the Search Results in a DataGrid.

The Toolbar class is defined as follows (non essential code removed for clarity):

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="100%"
	addedToStage="dispatchEvent(new Event('configureIOC', true))">

	<mx:Metadata>
		[ManagedEvents("search")]
	</mx:Metadata>

	<mx:Script>
		<![CDATA[
			import insync.parsley.events.SearchEvent;
		]]>
	</mx:Script>

	<mx:Label text="Search:" top="18" right="164"/>

	<mx:TextInput id="searchBox" right="0" top="16"
		change="dispatchEvent(new SearchEvent(SearchEvent.SEARCH, searchBox.text))"/>

</mx:Canvas>

Note that it dispatches a SearchEvent when the content of the search input field changes.

That event is defined as a managed event (using the ManagedEvents annotation), meaning that the framework will make sure that all the parties interested in that event will receive it.

How do you register as a listener for a managed event? You simply annotate a function with [MessageHandler], and it automatically becomes an event handler for that event, regardless of the display object hierarchy or whether the event bubbles or not.

Here is how it’s done in ContactList (non essential code removed for clarity):

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="100%"
	addedToStage="dispatchEvent(new Event('configureIOC', true))">

	<mx:Script>
		<![CDATA[

			import mx.controls.Alert;
			import mx.collections.ArrayCollection;
			import mx.rpc.events.FaultEvent;
			import mx.rpc.AsyncToken;
			import mx.rpc.AsyncResponder;
			import mx.rpc.events.ResultEvent;

			import insync.parsley.events.SearchEvent;
			import insync.parsley.services.IContactService;			

			[Inject]
			[Bindable]
			public var service:IContactService;

			[Bindable]
			public var contacts:ArrayCollection;

			[MessageHandler]
			public function searchHanlder(event:SearchEvent):void
			{
				service.getContactsByName(searchStr).addResponder(new AsyncResponder(getContacts_result, faultHandler));
			}

			private function getContacts_result(event:ResultEvent, token:AsyncToken):void
			{
				contacts = event.result as ArrayCollection;
			}	

			private function faultHandler(event:FaultEvent):void
			{
				Alert.show(event.fault.faultString);
			}		

		]]>
	</mx:Script>

	<mx:DataGrid id="dg" dataProvider="{contacts}" width="100%" top="0" left="0" right="0" bottom="0"/>

</mx:Canvas>

With the simple [MessageHandler] annotation, the handler will be invoked every time an event of the function argument’s data type is dispatched in the application. If you need finer control, you can use the selector notation to specify the event type. For example in MainView.mxml, we register the contactDeleted function as a handler for the ContactEvent.DELETED event as follows.

[MessageHandler(selector="contactDeleted")]
public function contactDeletedHandler(event:ContactEvent):void
{
}

There is more to the Messaging capabilities of the Parsley framework. For example, you can use [MessageBinding] to bind a property of an object to the property of an event.

[MessageBinding(messageProperty="result",type=" mx.rpc.events.ResultEvent")]
public var contacts:ArrayCollection;

Installation Instructions

1. Download the project here
2. Import it in Flex Builder
3. Run the application. The application is configured to use the MockService (ContactServiceMock) by default, so it will run without any back-end.

If you want to use the Remoting service instead of the MockService:

1. Replace <services:ContactServiceMock/> with <services:ContactServiceRemote/> in Config.mxml
2. Install the BlazeDS turnkey server.
3. Download insync-parsley-java.zip, and unzip it on your local file system.
4. Copy classes/insync to blazeds/tomcat/webapps/samples/WEB-INF/classes/insync.
5. Add the following destination to blazeds/tomcat/webapps/samples/WEB-INF/flex/remoting-config.xml:

<destination id="contacts">
        <properties>
            <source>insync.dao.ContactDAO</source>
            <scope>application</scope>
        </properties>
</destination>

6. Copy insync/sampledb/insync to blazeds/sampledb/insync
7. Edit server.properties in blazeds/sampledb, and modify the file as follows to add the insync database to the startup procedure.

   server.database.0=file:flexdemodb/flexdemodb
   server.dbname.0=flexdemodb
   server.database.1=file:insync/insync
   server.dbname.1=insync
   server.port=9002
   server.silent=true
   server.trace=false
   

8. Start the database (startdb.bat or startdb.sh)
9. Start BlazeDS
10. Run the application

In this second part, we will discuss how you can make these objects available to the views of your application without tightly coupling these views to the framework, and without passing references around through potentially many levels of view containment.

We will build the “Spring ActionScript” version of the InSync contact management application I often use in this blog to explore new technologies. The application has two views: MainView and ContactForm. Both need a reference to a contact RemoteObject to work.

NOTE: This example is intentionally kept simple. In a more partitioned application, you may want to pass a more abstract controller around as opposed to a specific RemoteObject. We will use this approach in part 3.

The views could use applicationContext.getObject() to access their dependencies (in this case the contact RemoteObject), but this approach has a number of problems:

1. With a dependency on applicationContext, the views would be tightly coupled to the framework.
2. We would still need to pass a reference to the applicationContext object to the views. This is often solved using the singleton approach which has its own set of problems.

So, instead of the views instantiating or looking up their dependencies, a better approach would be to “inject” these dependencies into the views.

Unlike Swiz, “Spring ActionScript” doesn’t currently have built-in support for an [Autowire] annotation, but Christophe Herreman seems to imply that this feature is coming, and in the meantime, he provides some sample code to support “Spring ActionScript”-powered autowiring in your application. Using this custom code, the inSync application looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	applicationComplete="applicationCompleteHandler()">

	<mx:Script>
	<![CDATA[

	import insync.views.MainView;
	import mx.utils.DescribeTypeCacheRecord;
	import mx.utils.DescribeTypeCache;
	import as3reflect.ClassUtils;
	import org.springextensions.actionscript.context.support.FlexXMLApplicationContext;

	private var applicationContext:FlexXMLApplicationContext;

	private function applicationCompleteHandler():void
	{
		applicationContext = new FlexXMLApplicationContext("applicationContext.xml");
		applicationContext.addEventListener(Event.COMPLETE, applicationContextComplete);
		applicationContext.load();
	}

	private function applicationContextComplete(event:Event):void
	{
		systemManager.addEventListener(Event.ADDED, addedEventHandler);
		var mainView:MainView = new MainView();
		addChild(mainView);
	}

	private function addedEventHandler(event:Event):void
	{
		var autowiredObject:Object = event.target;
		trace("Added to display list: " + autowiredObject);
		var typeInfo:DescribeTypeCacheRecord = DescribeTypeCache.describeType(autowiredObject);
		for each (var metaDataNode:XML in typeInfo.typeDescription..metadata)
		{
			if (metaDataNode.attribute("name") == "Autowired")
			{
				var propertyNode:XML = metaDataNode.parent();
				var property:String = propertyNode.@name.toString();
				trace("Found Autowired property: " + property);
				var objectName:String = property;
				var autowireByType:Boolean = true;

				for each (var arg:XML in metaDataNode.arg)
				{
					if (arg.attribute("value") == "byName")
					{
						autowireByType = false;
					}
				}

				if (autowireByType)
				{
					var clazz:Class = ClassUtils.forName(propertyNode.@type.toString());
					var objectNames:Array = applicationContext.getObjectNamesForType(clazz);
					if (objectNames.length == 1)
					{
						objectName = objectNames[0];
					}
				}
				trace("Autowiring: " + property + " in " + autowiredObject);
				autowiredObject[property] = applicationContext.getObject(objectName);
			}
		}
	}

	]]>
	</mx:Script>

	<mx:Style source="styles.css"/>

</mx:Application>

To be able to inject properties annotated with Autowired, we register as a listener for the ADDED event on systemManager, and introspect each object added to the display list. If the object has [Autowired] properties, those properties are injected (by name or by type) using applicationContext.getObject(objectName). This is also the approach taken by Swiz.

Timing

Before you inject objects into views, you need to make sure the applicationContext.xml file has been loaded and that the objects it defines have been instantiated. To that effect, the applicationContext dispatches an Event.COMPLETE event when it is ready. To make sure all the views of my application can be properly injected (if needed), the strategy I use in this application is to start instantiating the main view only after this event has been triggered. See addChild(mainView) in the applicationContextComplete handler.

The Views

With that infrastructure in place, the two views of the InSync application are easy to write. Their basic setup looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">

	<mx:Script>
		<![CDATA[

			import mx.rpc.remoting.mxml.RemoteObject;

			[Autowired]
			public var contactRemoteObject:RemoteObject;

		]]>
	</mx:Script>

</mx:Canvas>

Installation instructions

NOTE: If you already installed the Swiz version of inSync, you can skip steps 1, 3, 4, 5 and 6.

1. Install the BlazeDS turnkey server. (To be clear: you don’t have to use BlazeDS to use Spring ActionScript… That’s just what this sample is using.)
2. Download insyncspringas.zip, and unzip it on your local file system.
3. Copy insyncspringas/java/classes/insync to blazeds/tomcat/webapps/samples/WEB-INF/classes/insync.
4. Add the following destination to blazeds/tomcat/webapps/samples/WEB-INF/flex/remoting-config.xml:

<destination id="contacts">
        <properties>
            <source>insync.dao.ContactDAO</source>
            <scope>application</scope>
        </properties>
</destination>

5. Copy insyncspringas/sampledb/insync to blazeds/sampledb/insync
6. Edit server.properties in blazeds/sampledb, and modify the file as follows to add the insync database to the startup procedure.

   server.database.0=file:flexdemodb/flexdemodb
   server.dbname.0=flexdemodb
   server.database.1=file:insync/insync
   server.dbname.1=insync
   server.port=9002
   server.silent=true
   server.trace=false
   

7. Start the database (startdb.bat or startdb.sh)
8. Start BlazeDS
9. In Flex Builder, create a new Flex project called insyncspringas. You don’t have to select any “Application server type”.
10. Copy spring-actionscript.swc and as3reflect.swc from insyncspringas/flex/lib to the lib directory of your project
11. Copy the files and folders from insyncspringas/flex/src to the src directory of your project
12. Open applicationContext.xml and make sure the remoteObject endpoint value matches your server setup.
13. Run the application

Note on Autowiring and Performance

Annotation-based dependency injection is elegant and easy to work with. However, the current implementation that requires a describeType on every object added to the display list has a performance impact. This is maybe something that the Flex framework could help with in the future. For example, we could inject code at compile time to dispatch an AutowireEvent for each Autowired property when a class is instantiated. We would leave it up to the frameworks to provide a specific injection implementation. That would give these frameworks a better event to listen to, and they wouldn’t have to introspect all the objects added to the display list. An alternative would be to have a compiler hook to allow annotation-based code injection at compile time.

In the meantime, you’ll have to identify if the performance impact of the current approach is acceptable in the context of your application. If not, there are ways to improve the basic approach described above:

• Using Swiz, Aral Balkan uses an autowire property on the views that require autowiring. In the autowiring code, he then uses the hasOwnPropety(“autowiring”) function to identify if the object needs to be autowired before using describeType. This approach still requires some level of introspection on each object added to the display list.
• Swiz now makes sure it doesn’t perform describeType on classes in the mx packages. This approach could also be added to the code above.
• Another approach would be for you to programmatically dispatch an AutowireEvent in the initialize event of the views that need to be autowired. This approach is maybe less elegant than a simple annotation, but wouldn’t have the performance impact of introspecting all the objects added to the display list. It would also work for any object in your application, not only the views.