After I blogged a three-part Backbone.js tutorial (part 1, part 2, part 3), a number of people asked me to try Angular.js. So I decided to take it for a test drive. I thought it would be interesting to rebuild with Angular.js the Wine Cellar application I had built with Backbone.
[Read more...]
Sample Application with Angular.js
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.
Don’t miss the “Flex Frameworks” session at MAX
I’ve been working on putting together what should be a fun and informative session at MAX this year. The session is called: “Using Flex Frameworks to Build Data-Driven Applications”.
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.
Building a Flex Application with the Parsley Framework
After my recent explorations of “Swiz”, and “Spring ActionScript” (1,2,3), I decided to take the new version of the Parsley framework for a test drive, and build the Parsley version of inSync: the simple Contact Management application I often use to try out and demonstrate different features and techniques in Flex and Adobe AIR.

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:
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>
The "Spring ActionScript" Framework – Part 2: Autowiring
In the first part of this series, we looked at how the “Spring ActionScript” framework can help you externalize the configuration and the wiring of your components, and how you can easily obtain configured objects using applicationContext.getObject().
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:
- With a dependency on applicationContext, the views would be tightly coupled to the framework.
- 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:
RSS