Cairngorm – A glamorous pitfall, Is it? – Part I

When I started using Flex a few months back, the very first tings thing that crossed me was the fan-following for Cairngorm. It was amazing how could a framework be so popular, but they claimed to solve all the problems. It seemed a little good to be true, but was worth trying. Over a period of last two months, I have now realized that Cairngorm has quite a few shortcomings that leads to be an overly glorified framework that can not scale for any Enterprise Application, without any changes. “Without any changes” is the key here. With this Article, I start off a series of articles that is my attempt to explain why I feel Some things in Cairngorm need to change.

“Cairngorm is an implementation of design patterns that the consultants at Adobe Consulting have successfully taken from enterprise software development (with technologies including J2EE and .NET) and applied rich Internet application development using Adobe Flex.” – Quoted by Adobe Labs

The benefits of the Cairngorm architecture are realized when developing complex RIA applications with multiple use-cases and views, with a team of developers, and with a multi-disciplinary development team that includes designers as well as creative and technical developers. – Quoted by Adobe

Steven Webster follows up with series of articles explaining details on how to use Cairngorm. The goals that Cairngorm helps us achieve are:

1. Keeping State on the Client
2. Architecting the View
3. Feature-driven Development
4. Server-side Integration

In this article, I will talk about the “Keeping State on the Client” aspect of the Cairngorm and I will be referring to the “Cairngorm Store Web 2.1″ for any examples/references.

Steven introduces us to the Value Object pattern and the Model Locator pattern. As he quotes:

Many developers are familiar with the concept of MVC or Model/View/Control in application development, and wonder where state fits into this discussion. Quite simply, the state is the model.

In this case the ValueObject Pattern is one where you can use objects on the Client (Flex) and pass the same information to the back-end. If you are using LCDS/BlazeDS, then you get the benefit of using the same object in both the tiers. This is a great value add as developers do not have to maintain the overhead of heavy conversions on objects. Also, there are some tools available like XDoclet that will allow you to generate ActionScript objects from your Java POJOs and hence achieve quick and speedy results.

Model Locator pattern is the one that I find is the glorified pitfall. As Steven quotes again:

The Model Locator pattern is unique because it is not a pattern we borrowed from the Core J2EE Pattern catalog. Instead, we created this pattern particularly for Flex application development.Our motivation was to have a single place where the application state is held in a Flex application and where view components are able to “locate” the client-side model that they wish to render.

Great thinking, but the implementation is not what it should have been. A few of my observations:

1. Adobe has provided a marker interface “ModelLocator” which I do not understand why it is needed. The only driver that I can think of is to follow the OO practice – Develop against Interfaces and not implementations. Even though you would like to have your state/model divided into many ways, this does not makes sense. A Marker interface is used is you want to use things at Reflection, but in this case there is not such usage and is redundant. Model/state could have very well lived in the even without the Marker Interface

2. Use of singletons is where I believe which breaks the things. Steven quotes:

Having all the attributes on the Model Locator pattern as static attributes ensures that the Model Locator pattern is a simple implementation of a singleton. You ensure, for instance, that one and only one instance of a ShoppingCart exists per user.

Again, the intent is good, but the example that they took up is not at all good, is very bad. Let us take the example of the Cairngorm Store where they have used the Bindings to bind the Single Instance of the data to the view This simply couples the View with the State/Model and re-usability goes out of the window. <Kaboom/>. Code:

<details:ProductDetails
        id="productDetailsComp"
        width="100%" height="325"
        currencyFormatter="{ ModelLocator.currencyFormatter }"
        selectedItem="{ ModelLocator.selectedItem }" 
        addProduct="addProductToShoppingCart( event )" />

Consider a scenario, where in my application I want to use the component “ProductDetails” elsewhere, but as this component is now bound to the model/state, if I change the model, it effects the data elsewhere. Try adding the capability to compare the products, where you would like to re-use the same component to show the details in a comparative view. This component is useless and you can never get two different data sets to be bound to the same view.

But, do not just write-off this pattern – it is still very useful. All you folks who have ever developed the Web 1.0, know that a user’s session state is something that we have to manage in the HTTPSession and that was known as the state. You can use this pattern very well to do similar things like:

1. Manage User’s Session State and use the same to check for authorizations;
2. Show user;s navigation in the application. Almost all the applications have Breadcrumbs which should have just 1 state/model;
3. Current View/navigation state of the user i.e. -> ViewStack indexes/TabView indexes

I am sure that there are more, but I find this pattern very useful in many ways; just have to be careful that over usage of the same would lead to some serious trouble.

Singleton – Boon or a Sin

Over last few weeks, I have faced quite a few issues with Cairngorm’s Singleton pattern and I decided to put forward a post that should help in making some decision. While I found a few articles about Singletons, but not even one that talks about how should we use Singletons.

Ask any programmer, and they will instantaneously discourage you with the use of global data (objects). But, many a times when you find a need where you have to have some objects available globally and also need a single point of access example: User’s state, permissions which has to be retrieved globally across the user session. And, it is then when you use the design pattern singleton.

When is a class really a Singleton?

Ask yourself:

• Will every application use this class exactly the same way?
• Will every application ever need only one instance of this class?
• Should the clients be unaware of the application that this class is part of?

If you can answer all the above as a Yes, then you found a singleton – remember your Logger / Logging classes. Thats what you need as a singleton.

Now, let us switch focus to Flex, and how can we make use of a Singleton. As we all know that Flex is all about Events and thats how any two components interact wit each other. Singletons here become very handy, as you can dispatch en event on a Singleton Event Dispatcher and the component who needs to listen to it, can easily be listening on the Singleton. Solves many of our problems. Huh!! does it? I am putting down some code for the Buttons (which I am treating as a component). Try executing this code, and you will find that when you click on any one of the buttons, both the buttons handle the event and show and alert twice.

In my next article, I will explore the issues of Singleton with Cairngorm.

Flex is turning out to be fun

I ended my day yesterday, with quite a few things getting done, while other still open, but for sure it was a reveling experience. Flex was all over me most part of the day yesterday. Seems like catching up as I was on top the day before I said, I am liking it a lot.

This day some of the big ticket items that I worked upon were:

• Synchronous event processing – we were facing a lot of issues controlling the events as they get fired and how do we control the sequence as one could be dependent on the other. Tried using the Cairngorm ’s SequenceCommand. It works fine to dispatch events, but there is no way to go back to the previous event. The final solution is not there yet, but very close to what I want it to be. I think I will end up extending the Cairngorm framework to manage the same in the long run
• Command Pattern usage in Cairngorm: Does most of it, but the usage of the Command Deisgn pattern is missing. I need a few things in the long run which would lead me to extending the framework
• Layouts: Got a good grip on how to designing the layouts in Flex and have many areas of comparison. I am in a good position to write an article
• Runtime Shared Libraries: Some progress there as well. Got the resources to work with the RSL, still have to get my code built as an RSL

If you have already been through some of these, point me to some of those, meanwhile I will continue to work on providing detailed article to all of you.

I am now going back to have fun, you should too.