• .Net (10)
• AIR (8)
• as3 (8)
• Flex (21)
• Javascript (5)
• Misc.. (11)
• Ruby on Rails (8)
• Usability (6)

• June 2008 (6)
• May 2008 (1)
• April 2008 (1)
• March 2008 (1)
• January 2008 (3)
• December 2007 (2)
• November 2007 (6)
• October 2007 (9)
• September 2007 (5)
• August 2007 (2)
• July 2007 (1)
• April 2007 (4)

 

 

Oct
17

Simplified Cairngorm, Easy MVC for Adobe Flex

Posted: 17th October 2007
Tags: ActionScript, as3, easymvc, Flex, RIAs
Posted in Flex
Comments: 28 Comments »

Like many others, I have been struggling to fully get my head fully around the Cairngorm Micro Architecture, and even with the excellent Cairngorm Creator, I find it a little overkill for many Adobe Flex projects I am involved with, in fact, so does Steven Webster (one of the creators of Cairngorm).

So yesterday I sat in on an excellent Adobe eSeminar, presented by Tom Bray of SearcherCoders who presented an easy / simplified Model View Controller architecture based on Cairngorm.

To demonstrate the need for these frameworks, Tom started with an excellent example of an application based on a simple chat client. Inspired by his excellent Chatopica perhaps?:

1. <?xml version=”1.0″ encoding=”utf-8″?>
2. <mx:Application xmlns:mx=“http://www.adobe.com/2006/mxml“ layout=“vertical“>
3. <mx:Script>
4. <![CDATA[
5. import mx.collections.ArrayCollection;
6. [Bindable]
7. public var rooms:ArrayCollection = new ArrayCollection( ["Flex", "Flash", "AIR", "ColdFusion" ] );
8. [Bindable]
9. public var users:ArrayCollection = new ArrayCollection( ["John", "Paul", "George", "Ringo" ] );
10. [Bindable]
11. public var currentRoom:String;
12. [Bindable]
13. public var messages:String = “”;
14. private function joinRoom( room:String ):void
15. \{
16. currentRoom = room;
17. views.selectedChild = chatPanel;
18. \}
19. private function sendMessage( message:String ):void
20. \{
21. messages += message + “\\n”;
22. \}
23. ]]>
24. </mx:Script>
25. <mx:ViewStack id=“views“ resizeToContent=“true“>
26. <mx:Panel title=“Room List“ width=“300“ height=“400“>
27. <mx:VBox width=“100%“ height=“100%“>
28. <mx:List id=“roomList“ width=“100%“ height=“100%“
29. borderSides=“top“ dataProvider=“\{rooms\}“/>
30. <mx:Button width=“100%“ label=“Chat“ enabled=“\{roomList.selectedItem != null\}“
31. click=“joinRoom(roomList.selectedItem as String)“/>
32. </mx:VBox>
33. </mx:Panel>
34. <mx:Panel title=“Topic: \{currentRoom\}“ id=“chatPanel“ width=“500“ height=“400“>
35. <mx:HBox width=“100%“ height=“100%“ paddingLeft=“10“ paddingBottom=“10“
36. paddingRight=“10“ paddingTop=“10“>
37. <mx:VBox width=“150“ height=“100%“>
38. <mx:Label text=“User List“/>
39. <mx:List width=“100%“ height=“100%“ dataProvider=“\{users\}“/>
40. </mx:VBox>
41. <mx:VBox width=“100%“ height=“100%“ >
42. <mx:Label text=“Chat“/>
43. <mx:TextArea id=“chatText“ text=“\{messages\}“
44. editable=“false“ width=“100%“ height=“100%“ wordWrap=“true“/>
45. <mx:HBox width=“100%“>
46. <mx:TextInput id=“messageInput“ width=“100%“ minWidth=“0“/>
47. <mx:Button label=“Send“ click=“sendMessage( messageInput.text )“/>
48. </mx:HBox>
49. </mx:VBox>
50. </mx:HBox>
51. </mx:Panel>
52. </mx:ViewStack>
53. </mx:Application>

The above example application is a classic example of how most of us start out developing in Flex, we end up putting all our properties and event handlers in the same file. This may be fine for a tiny application but if we want to scale it up we are going to run into problems.

For example, Flex offers us the ability to create a custom MXML component, that we can then reuse through our application, so as Tom showed, maybe we want to take the code that displays the Room list (above) and copy this into a separate mxml component . We can easily cut and paste the code and create a new MXML file RoomList.mxml with the following code:

1. <?xml version=”1.0″ encoding=”utf-8″?>
2. <mx:Panel title=“Room List“ xmlns:mx=“http://www.adobe.com/2006/mxml“ width=“300“ height=“400“>
3. <mx:VBox width=“100%“ height=“100%“>
4. <mx:List id=“roomList“ width=“100%“ height=“100%“
5. borderSides=“top“ dataProvider=“{rooms}“/>
6. <mx:Button width=“100%“ label=“Chat“ enabled=“{roomList.selectedItem != null}“
7. click=“joinRoom(roomList.selectedItem as String)“/>
8. </mx:VBox>
9. </mx:Panel>

The problem is that we now have introduced two errors as the ArrayCollection ‘rooms’ is no longer in this mxml file then we cannot bind to it as the dataProvider for the roomList, also the event handler ‘joinRoom’ is no longer accessible. We could move these into this file, but then they couldn’t access the view stack and the problem goes on. So what we really need is to centralise our data into a central model and also centralise our even handlers into a controller.

Centralising Data into a Model

To centralise data, Tom took the Cairngorm’s modelLocator pattern, based around a singleton pattern . Where by the singleton ensures there is only ever one instance of itself, we define our Model as follows:

1. package com.chatopica.chat.model
2. {
3. public class ChatModel
4. {
5. private static var instance:ChatModel;
6. public function ChatModel()
7. {
8. if( instance != null )
9. {
10. throw( new Error( “there can be only one instance of ChatModel“ ) );
11. }
12. }
13. public static function getInstance():ChatModel
14. {
15. if( instance == null )
16. {
17. instance = new ChatModel();
18. }
19. return instance;
20. }
21. }
22. }

This is a typical singleton, implemented in ActionScript 3. As Tom pointed out in the eSeminar, ActionScript does not allow for private constructors, so here he is throwing an error if we try and instantiate the class and it is already instantiated. We can now access this Model anywhere in our application by simply typing

1. ChatModel.getInstance()

So the next thing to do is move our ArrayCollection rooms into the Model so we end up with the following:

1. package com.chatopica.chat.model
2. {
3. import mx.collections.ArrayCollection;
4. public class ChatModel
5. {
6. private static var instance:ChatModel;
7. [Bindable]
8. public var rooms:ArrayCollection = new ArrayCollection( [ new Room("Flex"), new Room("Flash"), new Room("AIR"), new Room("ColdFusion") ] );
9. public function ChatModel()
10. {
11. if( instance != null )
12. {
13. throw( new Error( “there can be only one instance of ChatModel“ ) );
14. }
15. }
16. public static function getInstance():ChatModel
17. {
18. if( instance == null )
19. {
20. instance = new ChatModel();
21. }
22. return instance;
23. }
24. }
25. }

Because our ArrayCollection is now in the Model that we can access from anywhere. We can change the mx:List ‘roomList’ in RoomList.mxml to use the rooms ArrayCollection in the Model as the dataProvider as follows:

1. <mx:List id=“roomList“ width=“100%“ height=“100%“ borderSides=“top“ dataProvider=“{ChatModel.getInstance().rooms}“/>

We have now fixed the first issue but we still have the issue of the click handler for the button being inaccessible. We can solve this by centralising our events into a Controller

Centralising Events into a Controller

As with many event driven languages, ActionScript has a handy feature known as event bubbling. When an event is fired in a container, if the event has been set to bubble (by default events don’t bubble) it will also fire on it’s parent container, and in turn fire on the grandparent container all the way up to the main Application MXML class. By bubbling events, we can register event listeners on the System Manager and listen for any global application events that are set to bubble. So we can dispatch an event anywhere in our application using the following, and we can listen for it on the System Manager:

1. dispatchEvent(new Event(‘myEvent‘, true))

Note: We have set the second parameter (bubbles) on the Event constructor to true, which tells the event dispatcher to bubble this event.

As we are centralising our events we may need to send related information along with the event, for use by the event handler. For example, as the event handler is no longer able to directly query the roomList, to see which item has been selected (i.e. roomList.selectedItem), we need to send this information with the event. We can easily do this by creating a custom event that extends the Event class as follows:

1. package com.chatopica.chat.events
2. {
3. import com.chatopica.chat.model.Room;
4. import flash.events.Event;
5. public class JoinRoomEvent extends Event
6. {
7. public static const JOIN:String = “joinRoom“;
8. public var room:Room;
9. public function JoinRoomEvent( room:Room )
10. {
11. super( JOIN, true );
12. this.room = room;
13. }
14. }
15. }

Above we have simply extended the event using inheritance and have added a public property called room (of type Room, Tom has created a Room class that holds the name as well as a collection of Users). We have also declared the event name/type as a constant JOIN = “joinRoom”. This allows us to reference this event anywhere. In our constructor, we call the constructor on the parent class (Event) setting the event name/type to “joinRoom” and stating that it should bubble (like this we don’t have to specify that it bubbles when we create a new JoinRoomEvent). We then set the room property from the parameter passed to the constructor.

So now we can fire a JoinRoomEvent anywhere in our application, passing in a room object. The event handler listening for this event will have access to this room object. So we can fix the last error in RoomList.mxml as follows:

1. <mx:Button width=“100%“ label=“Chat“ enabled=“{roomList.selectedItem != null}“
2. click=“dispatchEvent( new JoinRoomEvent( roomList.selectedItem as Room ) )“/>

So far we have created a custom event and we have discussed where to look to find bubbling events but we have not looked at how to do this.

The Controller

As I mentioned before, we can listen to all events that have been set to bubble on the systemManager and as UIComponent (anyone who has created a custom component will know this one) has a reference to systemManager within it, we can extend this class. The other benefit of extending UIComponent for our class that will be our central event handler or Controller is that we can then use it in MXML.

We extend the UIComponent as follows:

1. package com.chatopica.chat.controller
2. {
3. import com.chatopica.chat.events.JoinRoomEvent;
4. import com.chatopica.chat.events.SendMessageEvent;
5. import com.chatopica.chat.model.ChatModel;
6. import flash.events.Event;
7. import mx.core.UIComponent;
8. import mx.events.FlexEvent;
9. public class ChatController extends UIComponent
10. {
11. public function ChatController()
12. {
13. addEventListener( FlexEvent.CREATION_COMPLETE, setupEventListeners );
14. }
15. private function setupEventListeners( event:Event ):void
16. {
17. systemManager.addEventListener( JoinRoomEvent.JOIN, handle_joinRoom );
18. }
19. private function handle_joinRoom( event:JoinRoomEvent ):void
20. {
21. ChatModel.getInstance().currentActivity = ChatModel.VIEWING_CHAT;
22. }
23. }
24. }

Note:: Above we have not directly added an event listener to the systemManager in the ChatController constructor. In fact we can’t to do this, because at the time the class is instantiated the systemManager is not initialised and is Null. We would therefore be adding an event listener to nothing. We get around this by adding an event listener for the global FlexEvent.CREATION_COMPLETE event, and at that point we can then add our event handler(s) to the systemManager.

Controlling the View Stack

The final thing we have left to achieve is the ability to change the View Stack from the controller, we first need to store the currentActivity or state in the Model as follows:

1. public static const VIEWING_CHAT:String = “viewingChat“;
2. public static const VIEWING_ROOMS:String = “viewingRooms“;
3. [Bindable]
4. public var currentActivity:String;

In addition to the currentActivity property above, we have also added a constant value for each state. Unfortunately it is not as simple as binding this property to the mx:ViewStack, but that does not mean it isn’t easy. All we have to use is the ChangeWatcher class that monitors a property and fires and event when it changes. We do this in the file MainView.mxml that holds out viewstack as follows:

1. <?xml version=”1.0″ encoding=”utf-8″?>
2. <mx:ViewStack xmlns:mx=“http://www.adobe.com/2006/mxml“ resizeToContent=“true“ xmlns:views=“com.chatopica.chat.views.“>
3. <mx:Script>
4. <![CDATA[
5. import mx.events.PropertyChangeEvent;
6. import mx.binding.utils.ChangeWatcher;
7. import com.chatopica.chat.model.ChatModel;
9. private var activityWatcher:ChangeWatcher = ChangeWatcher.watch( ChatModel.getInstance(), "currentActivity", handle_activityChange );
11. private function handle_activityChange( event:PropertyChangeEvent ):void
12. {
13. if( event.newValue == ChatModel.VIEWING_CHAT )
14. {
15. selectedChild = chatPanel;
16. }
17. }
18. ]]>
19. </mx:Script>
21. <views:RoomList/>
23. </mx:ViewStack>

Now, when the value of currentActivity in the ChatModel changes, Flex will dispatch a PropertyChangedEvent. We can then listen for this event and change the view, accessing what the new value of currentActivity is in the newValue property of the PropertyChangeEvent (shown above as event.newValue).

Refactor the rest of your application…

Having done this for the RoomList component, we can now repeat the process for the code that implements the chat window. Finally we are simply left with the following in our mx:Application tags:

1. <?xml version=”1.0″ encoding=”utf-8″?>
2. <mx:Application xmlns:mx=“http://www.adobe.com/2006/mxml“ layout=“vertical“ xmlns:views=“com.chatopica.chat.views.“ xmlns:controller=“com.chatopica.chat.controller.*“>
3. <controller:ChatController/>
4. <views:MainView/>
5. </mx:Application>

This process now makes our code cleaner, loosely coupled and more DRY (Don’t Repeat Yourself), easy to scale and we can reuse these components without the risk of breaking our system.

Thanks again to Tom for the excellent eSeminar which has really clarified my understanding for the necessities of using an architecture like this.

Source code for this example was kindly supplied by Tom Bray, you can download them directly from his blog.

A transcript of the questions and answers session from Tom’s eSemminar, is also available on his blog

Update 23/01/08: I have added an article on scaling up EasyMVC, you can read it by clicking here.

For more information:

• Tom Bray
• Chatopica
• SearchCoders
• Adobe Flex

Comments below..

Comments

Note: You can leave a response, or trackback from your own site.

• Home
• About
• Design & Development
• Extras…
• Contact
• RSS Feed
  

• Categories
• .Net (10)
• AIR (8)
• as3 (8)
• Flex (21)
• Javascript (5)
• Misc.. (11)
• Ruby on Rails (8)
• Usability (6)

• Archives
• June 2008 (6)
• May 2008 (1)
• April 2008 (1)
• March 2008 (1)
• January 2008 (3)
• December 2007 (2)
• November 2007 (6)
• October 2007 (9)
• September 2007 (5)

• Recent Blog Articles
• » Poor Blog Performance
• » Building a medium to large scale Flex App using Cairngorm (Part 4)
• » Building a medium to large scale Flex App using Cairngorm (Part 3)
• » Building a medium to large scale Flex App using Cairngorm (Part 2)
• » Building a medium to large scale Flex App using Cairngorm (Part 1)