As much as I love Flex, I haven't been too impressed by the frameworks that have emerged yet.

Now, let me be clear by saying that most of the work I do these days is either in Java on the back end or at the architectural/conceptual level, and my experience with building a full blown app in Flex is still pretty limited. However, I have tinkered enough to know what I like and what I don't, and some of our top talent at CFI comes by my office regularly to let me know when they are experiencing challenges. So, some of what I write in the post will be my own experience, and some of it will be anecdotal based upon the experiences of others.

With that said, let's get back to the main event.

When we started doing Flex development at CFI, we jumped in to Cairngorm because it was something of a de-facto standard; and let's be honest, nothing much else existed at the time. We were on Flex 1.5, I had a copy of the "Developing Rich Clients with Macromedia Flex" book, and liking most of what I read in there I felt that the authors knew what they were doing, and since they had also authored Cairngorm it seemed like a good place to start.

Is Cairngorm bad? I wouldn't say so. It's a clean framework implementation and it addresses some of the idiosyncracies associated with asynchronous application development. However, it is an awful lot of work to get an application to do anything in Cairngorm; there are many layers, some of which I found to be rather tedious when I was working with it, and some of our Flex developers felt the same way. One even went so far as to customize some Cairngorm-internal classes to get the framework to be a little easier to manage.

We've also had some discussions internally about how Cairngorm's implementation approaches the Front Controller pattern, and this is not necessarily ideal for rich application development. Flex can maintain state, and it would make sense for a Flex framework to leverage the statefulness of the front end in any framework that might be developed for it. I'd also like to see frameworks emerge with minimum boilerplate, and there seems to be an abundance of boilerplate in Cairngorm based upon both my limited experience and the feedback from our developers building Cairngorm apps in-house.

Let's switch gears for a second, and go to the other extreme.

A few months back, I went to the OJUG meeting where James Ward was demoing some Flex apps. I had been out of the Flex development arena at work for a while, and wanted to see what James had to say as well as check out the local JUG. James put on a great presentation as always, and it was the usual Flex drill of features and demoing the performance and experience capabilities that I was already familiar with.

We had been having the "is Cairngorm what we want" discussions at CFI right before I went to the OJUG meeting, and something happened in James's preso that made me think about the far end of the spectrum for simple Flex app development. When James demo'd his Flickr widget, I was struck by the simplicity of it: drop the Flickr widget tag on the page, bind another UI component to a public array property of the Flickr widget that would fill with images, and make a call to the widget to perform a service call that would ultimately fill the array and populate the UI component through data binding. No controllers, no listeners, and yet a simple pair of encapsulated, purpose-built objects that could be reused in any application.

Seeing this in action, it reminded me of what I loved about Flex's ability to create simple observer relationships using data binding, something that had been so painful in my Java Swing days (damn you, ActionListener! :) ). It also reminded me that the technology in Flex should be treated differently to traditional web technologies, and that perhaps a reasonable middle ground could be found between traditional MVC web frameworks and simple bindings in Flex. Ideally, I'd like to see a bare minimum of useless boilerplate and maximum productivity, and I imagine every Flex developer would agree.

So then, a week or two back, Cliff Hall released a demo Apollo app (CodePeek) for his fledgling PureMVC framework. I looked through the architectural documentation on the web site and the sample code in the demo app, and felt like things were moving in the right direction. I like Cliff's approach to the framework, and while there is still some boilerplate, it's minimal.

If anything, the framework is almost too minimalistic in its present form. For example, as the application kicks itself off, it's necessary to announce an event in the main MXML file to start up the app, which fires off a MacroCommand to fire two other commands initializing the Model and the View. In order for this to take place, commands have to be created for initializing the Model and View, and the APP_STARTUP command has to be explicitly denoted, created, and listened for. Model and View initialization seems like a fairly standard operation that almost every, if not all, applications utilizing PureMVC would need to take place in order to be functional, and as a result, this is the sort of thing that could be simplified by creation of a convention or simple configuration that saves the developer from doing these steps. Of course, Clff has done a nice enough job with the framework that any developer could make these simple extensions themselves, but having been spoiled by Spring for Java for so long I guess I'm just used to seeing built-ins like this in a mature implementation.

There were some other things in the PureMVC demo app that I thought I would do differently. For example, the AppControlBar and AppControlBarMediator objects are pretty tightly bound, but it seemed like Cliff went out of his way to try to keep them loosely coupled.

In AppControlBarMediator's constructor, there are three lines of code registering event listeners so that the mediator can pick up events from the AppControlBar. The AppControlBar then has to define specific functions to announce these events (another six lines of code). Once the AppControlBarMediator catches the events, it does nothing but invoke the appropriate proxy, but only after referencing specific properties of the AppControlBar using dot property notation.

Having discussed this with my buddy Russ at work (easily our most experienced Flex developer, and a very sharp fellow besides that), we agreed that using an event registration/announcement model would allow the AppControlBar component to be reused in other applications. I can see the point for completely reusable components, but this control bar is so specific to the application in question that all the event registration code seemed like overkill, especially if the mediator is just going to break the encapsulation of the component in order to get the properties to pass to the appropriate proxy.

In this simple use case, it seems like it would be simpler and just as clean to make the AppControlBar an MXML component that announces events containing the appropriate data, which the AppControlBar would prepopulate, thus decoupling the View's internal properties from the Mediator. Then, we could treat the Proxy as a component also, exposing a publicly available service method. Next, we would embed the AppControlBar and a service-located reference to the Proxy in an MXML file that links the event ennouncement from the AppControlBar to a service method invocation on the proxy. Finally, the Proxy could announce an event once the service call returns. We'd listen for this event in the MXML file containing the AppControlBar and the reference to the Proxy, which could handle the event by manipulating the AppControlBar through a publicly exposed method. Taking this approach, the containing MXML file becomes the Mediator, as a kind of blend between an XML config file and a code file.

With an appropriate amount of abstraction in the nature of/access to the proxy and the AppControlBar's interactions with it, I think this sort of approach would eliminate the boilerplate code and could still extoll the virtues of a clean MVC framework. With a simple mechanism for interested parties to listen for events from the Proxy (similar to the excellent job Cliff has done in PureMVC) and a twist in the Mediator concept that would use the MXML file containing the components as something of a blend between a purpose-built controller and an IoC configuration file, I think that a great balance could be struck.

Either that, or my limited exposure to full scale Flex development is blinding me as opposed to letting me think openly, and I'll be back here eating my words in a few weeks. In any event, the combination of our semi-pain with Cairngorm, the simplicity of James Ward's Flickr widget demo inspiring me, and Cliff's excellent work on PureMVC, I'm going to take a stab at building a proof of concept app that hits this middle ground. As I identify opportunities for reuse, I'll try to break those out in to reusable/configurable components, and maybe a framework of sorts will emerge.

And if (worst case) this all falls apart, I'll come back to the table with a more in-depth understanding of the design behind the Flex frameworks that exist today, which can't be a bad thing.