MATE: Responding to events

Recently, I embarked on a personal project to learn about the Mate Framework, which I’ve started hearing more and more about. We’ve successfully used Cairngorm in dozens of Flex/AIR projects at Enpresiv and I thought it was time to try out Mate (apparently pronounced mah-teh).

I’m glad I did, because it is an awesome framework with much flexibility making it suitable for many different types of projects. One of my favourite things about the framework is how quick and easy it is to integrate. It doesn’t force you to use all Mate concepts either, providing endless options for partial integration into existing projects that might just need a little structure.

One of the issues with Cairngorm that a lot of people have trouble with is easily responding to events/commands within a view (albeit the event that dispatched the event or not). I was happily surprised when I found out this is one of the easiest things to do within Mate, and there are two ways to do it!

Mate advocates the Dependency Injection pattern over the Model Locator pattern which Cairngorm advocates. Dependency Injection is a fantastic concept and truly promotes reusable views as the view needs no knowledge of the framework. Your view doesn’t really need to respond to an event directly, it just receives only the required or updated data it needs.

The second means for views to directly respond to events is using the Listener tag, which simply could not be any easier to work with.

I’ve worked up a basic yet focussed example on two options for repsonding to Mate events within views.

I plan on discussing other Mate features in future posts, but thought this was a great starting point as it’s the source of pain for many Cairngorm developers. Although, Universal Mind have released some extensions which make responding to events/commands within views much easier.

Filed under: cairngorm, flash platform, flex, frameworks, mate

View Notifications: responding to Cairngorm Commands in the View

As I’ve previously mentioned, we’re in the early architecting stages of a Flex application and we’re being confronted with some key decisions to be made. I think some these might be useful so I’ll continue my Flex based posts during the project.

The basic premise of Cairngorm and the ModelLocator pattern is that each Command (responsible for retrieving data from the server via the ServiceLocator pattern) retrieves the data and then updates the Model with the new data. In turn, your Views can then respond to changes in the Model via Flex’s baked-in data binding. This is one of the most useful features of Cairngorm and makes it perfect for large scale Flex applications.

But what about the times when you don’t want the Command to change the Model? One of the downsides of the ModelLocator pattern is if you go sticking everything in the model, it will quickly become polluted.

There has been much discussion in the past about how to best deal with this situation:

• Alex Uhlmann’s post How Business Logic Can Manage Views
• Derrick Grigg’s post Cairngorm, Commands, Views and Harikiri
• Thomas Burleson’s Cairngorm View Notifications

This time around we chose Thomas Burleson’s View Notifications resolution. It seemed to make perfect sense, it was clean and easy to achieve.

After successfully implementing it (which really was simple), I can definitely recommend View Notifications as a means to respond to Commands directly within your Views!

It seems Thomas and the Universal Mind team are looking to formalise this and some of their other Cairngorm extensions.

Filed under: cairngorm, flash platform, flex

Editing VOs in the model?

We’re working on a Flex application at work, using Cairngorm, and we’re in the early architecting stages of the project.

We have a datagrid showing a list of clients (an ArrayCollection containing ClientVOs, which lives in model.clients).

We need to provide the functionality to edit a ClientVO, and save the data back to the database. When constructing the edit view we had to decide to either pass the ClientVO to the view by reference or to pass the ClientVO to the view by value.

The events we had to manage when exiting from the ClientVO edit view where:

• Save. Save the ClientVO to the database, but do not exit the edit view.
• Done. Save the ClientVO to the database and exit the edit view.
• Cancel. Exit the edit view and discard any changes.

The Cancel event basically forced us to pass the ClientVO to the view by value, which gives you great flexibility on editing a local (to the edit view) version of the ClientVO.

However, it does mean you need to force the edited ClientVO back into model.clients (so that the datagrid contains the new values) at the correct index, effectively replacing the old version of the ClientVO and not an unrelated ClientVO.

I’m not sure if there is a Design Pattern that supports this, or demonstrates how to handle this better.

Filed under: cairngorm, flash platform, flex

Cairngorm Stub Files

I really like Cairngorm, I think it is an excellent framework to build RIAs in. I just don’t like all the work, memory involved in setting it up all the time.

I’m not really sure how others do this, but I usually grab an example application (such as the Advanced Cairngorm Store) and start ripping out all the bits and pieces I don’t need. This is a laborious and boring task, so I decided to do something about it.

I created a set of Cairngorm Stub Files (setup under the com.example path). They contain stub-code/files for most of the Cairngorm infrastructure that you would usually use in a Cairngorm project.

The files make a nice starting point, and because there are so many bits and pieces to the Cairngorm Framework, they also act as a nice cheat sheet to all of the classes, and patterns in Cairngorm.

Let me know if you find any bugs and I’ll update the stub files.

Filed under: cairngorm, flex