everynerd.net

It’s no surprise to developers that the requirements for an application are bound to change, and it’s because of this fact that there are numerous architectures for developing software applications that can ease the process of adding new functionality. 

For Flex specifically, one such architecture is Cairngorm, which has been described here a few times. But as easy as it is to manage important events in the application, even the best architecture fails to simplify a project.  It always gets to a point where there are too many pages to keep track of.

Using a personal example, the backend administration tool that has been in development for my entire tenure at the company (and as such, requirements have shifted dramatically over this time period) has grown to house a fairly large number of major components. Two types of search pages, two types of master-detail pages, a login page, two types of general site maintenance pages and a number of custom renderers and other compents necessary for image retrieval and display.

How does one keep track of all these different areas that a user is supposed to seamlessly surf through?  At first I had a show/hide game going on, but after about 3 different major compents were in use, the process became unmanageable. 

Then I discovered States.

Using the ModelLocator of the Cairngorm architecture, I decided to hold two significant states: the authentication state, and the application state. Both variables declared as strings.

Here’s how the format of the application implements states:

MainApplication.mxml -> Two states: Valid, or invalid.  

When this loads, it dispatches a Cairngorm event to check if a user session exists (via amfphp, to a Zend_Auth controller), if does then the variable for authentication state in ModelLocator is set to “valid”, if not it is set to “invalid”.

In the MainApplication.mxml file, two states are listed such:

1
2
3
4
5
6
7
8
9
10
11
12

<mx:states>
	<mx:State name="invalid">
		<mx:AddChild>
			<mx:LoginComponent />
		</mx:AddChild>
	</mx:State>
	<mx:State name="valid">
		<mx:AddChild>
			<mx:WrapperComponent />
		</mx:AddChild>
	</mx:State>
</mx:states>

The currentState property of the application is bound to the ModelLocator variable for authentication state. So in the event that this property changes to either of these states, the child component will be loaded.

In the case of the administration tool, one of these is a login form and the other is a wrapper component for the next tier of major components. For this example it is called WrapperComponent. Its currentState property is bound to a separate ModelLocator variable to control the general application state.

This solved the problem of having to manage N different components in a complex administration system, and now the code will only need to manage the application state variable and the rest is taken care of.

For added flair, states can also have transitions set to them. Which if done correctly and sparingly, can really add to the look and feel of an application.