MAX Frameworks Session: One Application, Four Implementations (Code Available)

This year at MAX, I organized a “Flex Frameworks” session called “Using Flex Frameworks to build Data Driven Applications”. I wanted to stay away from a high level / rhetorical debate or panel. I also did not want a session aimed at proclaiming a (subjective) winner. What I had in mind was a pragmatic session that would provide developers with the information they need to make their own decision based on their background, the type of applications they build, and their own style and preferences.

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.