Delegate Factories with Prana

I've been having fun with Prana lately. Prana is an IoC container framework for Flex under development by Christophe Herreman. Prana is sort of built with Cairngorm in mind, but it could work for any configuration and injection you wanted to do at runtime.

One of the benefits I can see is for rapidly prototyping an application with little to no knowledge of the service you may need to connect to for your data needs. If you can define the data model well enough, you could build your application with Cairngorm in such a way that all you'd need to do is change one file (or type of file): the Delegate.

That's the reason for the business delegate: to keep the application isolated from the implementation of the service layer.

I've written up an example of how I'm currently using this on a project and posted it at http://labs.effectiveui.com/examples/prana/delegates/. It's a pretty lame sample, but if you right click and select "View Source", it shows how I have created a DelegateFactory that gives my commands a Delegate that conforms to a certain interface. Then, using Prana, I can configure the DelegateFactory to build whichever implementation of the Delegate I wanted, without recompiling the application.

The benefit is that I can drive the application's data from dummy xml data, but the application doesn't care where that data comes from. As long as I'm write about the way the data looks, my Commands don't need to change once I switch over to a production ready Delegate.

First, look at the DelegateFactory. Notice that it contains a string, _delegateClassName which will contain the qualified name of the class I want the DelegateFactory to make. There's some type-checking in there once that string is set to make sure that points to a class that conforms to the interface. One last thing to notice is that I need to have the class of the delegate referenced at least once in the code so that it's compiled in. That happens on the line that says

private static var compileTheseClasses:Array = [DevDelegate]


So DevDelegate is the delegate I want to use at development time. That Delegate acts like a regular delegate that calls an HTTPService to get some xml. Instead of doing that, though, it just loads xml local to the swf and sends a ResultEvent to the LoadPeopleCommand as if a result had just returned from the HTTPService.

Once last thing to notice is the applicationConfig.xml which drives Prana. It's loaded by the InitializeCommand. In that first block there:

<object id="delegateFactory" class="com.effectiveui.examples.business.DelegateFactory" factory-method="getInstance">
<property name="delegateClassName" value="com.effectiveui.examples.business.DevDelegate" />
</object>


I tell Prana to configure my DelegateFactory with the delegate class I want to use. I can change this xml file at runtime, so as long as I make sure the Delegate is compiled in, I can change delegates whenever I need.

Of course that's just one of the uses of Prana, but I really like the ability to get up and running easily by making a development time delegate.

Flex needs a Custom Metadata Class

At MAX, I was really surprised to find out a sekret Flex compiler feature: You can keep custom metadata around in your Flex app. There's a tutorial with a really sweet proposed application for that feature at Christophe Coenraets' Blog.

The only thing about that example is that the entityManager needs to know to read the objects passed into its save() method for metadata. That's not a problem for that use case. BTW, you can read metadata with describeType()

What if I wanted to copy more of the JPA with Flex? Then I'd need the FPA (a mythical Flex Persistence API) to manage the instantiation of the EntityManager and pass in a reference at runtime. I'd need to inject the right EntityManager into any code that wanted it. Right now to do something like that we'd need to read every class, or intelligently read certain classes, to figure out if there were annotations to deal with.

It'd be nicer if we had a first-class Metadata class that got instantiated by the framework at runtime and knew about the class it decorated. That way it could do things like negotiating with the "FPA" to get the right EntityManager at runtime based on configuration data. It could then modify the object that had the metadata with no developer intervention. It'd look something like this, following Christophe's example:


[PersistenceContext(id='applicationPersistenceContext')]
public var entityManager:EntityManager;


That would mean that at runtime, the 'applicationPersistenceContext' persistence context, which could contain data about which database in SQLLite to use, maybe usernames and passwords or something like that... in short: configuration you don't want compiled into your code. That PersistenceContext object would know to inject the correct EntityManager into the variable 'entityManager'.

I think it'd be a great addition to the framework which would allow a lot more use of the "Dependency Injection Pattern" to help make easy to use frameworks for specific needs on top of Flex.

I've created an enhancement issue here: https://bugs.adobe.com/jira/browse/SDK-13002 If you agree, make sure you vote on the issue.