Flex – Cairngorm Sample Application
The last articles explained the basics behind a Cairngorm based Flex application. Now it’s time to get hands on a working example. The Address Manager is very simple, it organizes and manages contacts. The data is stored on the server in a small SQLite database. Flex is in charge for the interface, the view logic and for dealing with user interactions. The remote communication is done by AMFPHP. Let’s look at some important parts ot the application.
Business Object
As your application grows, the ModelLocator might become overcrowded with properties and functions. A common solution is to create single business objects that encapsulate sections of your logic and model. They represent the information your view needs in a special context.
In the example, the complete form handling is done by the AddressModel class. The main ModelLocator references it via a public property which can be referenced in your code.
<view:FormComponent addressForm="{modelLocator.addressForm}" address="{modelLocator.addressForm.address}"/>
</mx:HBox>
States for controlling the view
The input form component is used for adding a new contact and for editing an existing one. Its different characteristics for each case (headline, event handling, button labels) are controlled by states. The currentState property is used to get bound to the model. So whenever you switch between adding and editing, the model changes and activates the needed state.
<mx:State name="update">
<mx:SetProperty target="{headline}" name="label" value="Edit Address"/>
<mx:SetProperty target="{button}" name="label" value="Update"/>
<mx:SetEventHandler target="{button}" name="click" handler="doUpdate()"/>
<mx:AddChild relativeTo="{buttonCancel}" position="after">
<mx:Button id="buttonDelete" label="Delete" click="{deleteAddress()}"/>
</mx:AddChild>
</mx:State>
<mx:State name="add">
<mx:SetProperty target="{headline}" name="label" value="Add Address"/>
<mx:SetProperty target="{button}" name="label" value="Add"/>
<mx:SetEventHandler target="{button}" name="click" handler="doAdd()"/>
</mx:State>
</mx:states>
Validating user input
Validating user-input in RIAs is a common task. Of course, validation should be done again on the server side. But pre-checking it on the client reduces communication traffic and allows a much faster response to errors. The mx:Validators do a good job here as they even validate during user input. Their funtionality can also used by some commands. The Validator.validateAll() method expects an array with all validator objects to check. It returns another array with invalid objects. By checking the result, the command can decide whether to submit the form or to discard the input.
var addEvent:AddEvent = event as AddEvent;
// do validation here
if(modelLocator.addressForm.validate().length > 0) return;
// create delegate and set responder
var delegate:AddDelegate = new AddDelegate(this);
delegate.add(addEvent.address);
}
Invoking actions on the view
Sometimes a state change within your model should cause some action on the view, like showing an Alert. Creating this control is something only a view should be concernd with, just like manging states. Following a binding approach, you can bind a property of the model object to a method on the view which is calles while the value changes. Instead of using the mx.Binding tag, Paul Williams Observer does a better job here as it offers a better API and allows the binding to listen for specific values
Value Objects for data exchange
Both parts of the application, the backend services and the Flex frontend use Value Objects to exange address data. The AMF-format allows a complete class mapping. So it is very easy to send typed objects from Flex to your server side scripts and vice versa. This allows a seamless integration of both sides.
To prepare your PHP class for this mapping, you must add an explicit mapping type:
View the application and download the sources: Flex AdressManager application
Comments are closed.