Using the Flash Builder 4 Data Centric Features with Parsley (and other frameworks)

I have blogged about the new data-centric features in Flash Builder 4 here and here. One question people often ask me is: “Can I use this feature if I use a Framework (Cairngorm, Mate, Parsley, Spring ActionScript, Swiz, etc)?”

The answer is yes: The classes generated by Flash Builder (Value Objects and Service Stubs) are standard building blocks that are part of most RIA design patterns, regardless of whether or not you use a framework.

The way you leverage these classes in your application may differ slightly depending on the framework you are using. For example, each framework may have a different approach to configure service endpoints or to instantiate generated service stubs.

To demonstrate this, I built a version of my “Contacts” application (also known as InSync) using the Flash Builder 4 data-centric features and the Parsley Framework.

Configuring Service Endpoints

By default, an application built using a BlazeDS or LCDS project determines its service endpoints using a combination of assumptions made at runtime and hardcoded references baked into the swf at compile time. Read my Externalizing Service Configuration blog post for more information on this topic. The bottom line is that this default behavior is insufficient for any application other than a simple demo: you want endpoints to be fully configurable so that you can move services around without having to recompile your application.

Using Parsley, I inject the service endpoint configuration (in the form of a ChannelSet) in the generated service stubs as follows:

public class ContactService extends _Super_ContactService
{
	[Inject]
	override public function set channelSet(cs:ChannelSet):void
	{
		super.channelSet = cs;
	}
}

Note that I added this code in ContactService.as and not _Super_ContactService.as. Contrary to _Super_ContactService.as, ContactService.as will never be regenerated and is therefore the right place to add your custom code.

The injected ChannelSet is defined in my own channels-config.xml configuration file as follows:

<object type="mx.messaging.ChannelSet">
 	<property name="channels">
    		<array>
		    	<object type="mx.messaging.channels.AMFChannel">
		        	<property name="uri" value="http://localhost:8400/testdrive/messagebroker/amf"/>
		        </object>
	        </array>
	</property>
</object>

Note: Unlike the BlazeDS/LCDS services-config.xml file, channels-config.xml is read at runtime.

Because the ChannelSet is configured in an xml file, you can easily change the channel’s endpoint URI without recompiling the application. You could also add failoverURIs to this channel, or add completely new fall back channels to the ChannelSet.

Instantiating Service Stubs

As we already alluded to, Parsley is a dependency injection framework: Instead of letting a component instantiate its dependencies, those dependencies are injected in the component at runtime. For example, in ContactForm, instead of instantiating a ContactService as follows:

<services:ContactService/>

… I simply defined a contactService reference variable that I annotated with [Inject] to let Parsley inject a ContactService instance a runtime.

[Inject]
public var contactService:ContactService

The instance of ContactService that Parsley injects is defined in Config.mxml and has itself been injected with a ChannelSet. Object configuration in Parsley is very flexible. In this application I combine the xml and mxml configuration options. I use the xml configuration option for the things I don’t want to hardcode in my application, and the mxml configuration for traditional object instantiation and configuration.

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. 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.

Installation Instructions

1. Download and install BlazeDS 4
2. Make a copy the blazeds web application in blazeds/tomcat/webapps, and call the new web application contacts
3. Download contacts.zip, and unzip it anywhere on your file system.
4. Overlay contacts/webapps/contacts (from contacts.zip) on top of blazeds/webapps/contacts
5. Start the server
6. Open a Command Window or Shell, navigate to /blazeds/tomcat/bin, and start Tomcat (for instance: catalina run).
7. Open a browser and access http://localhost:8400/contacts/ContactsParsley/ContactsParsley.html.

Note: The web application also include a plain (framework-less) version of the application available at this URL: http://localhost:8400/contacts/Contacts/Contacts.html

Importing the projects in Flash Builder 4

1. In Flash Builder 4, click File > Import > General > Existing Projects into Workspace.
2. Specify contacts/projects as the root directory and click finish.
3. Explore the projects: Contacts is the Flex project for the plain version of the application, ContactsParsley is the version discussed in this article, and java-testdrive is the Java project for the server-side classes.