Trygve Reenskaug is credited with the first MVC formulation in Smalltalk in the late 70′s. However, the MVC metaphor was burned into Smalltalk and matured after Reenskaug left Xerox Parc. I found two useful resources on MVC in Smalltalk-80. The first is  A cookbook for using the model-view controller user interface paradigm in Smalltalk-80 by Glenn Krasner and Stephen Pope. The second resource is Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC) by Steve Burbeck.

Although comprehensive, Krasner and Pope’s article is very readable from an ActionScript perspective. I could just about follow the Smalltalk code listings, identify the early OOP features and appreciate the ancestors of contemporary UI components.  What stood out was how little things have changed in the last 20 to 30 years in OOP and GUI programming. I think the more appropriate observation is how advanced Smalltalk was for its time. Krasner and Pope’s essay is the primary resource for this post.

Model-View-Controller Implementation in Smalltalk-80

The MVC pattern facilitates the separation of concerns when developing interactive graphical applications. The logic and state of the application, how users interact with the application, and how application state is presented to the user are handled by separate elements of the MVC triad. Smalltalk-80 uses the MVC metaphor to provide built-in support for interactive application development. The idea was to provide a set of built-in user interface widgets such as buttons, menus and lists that can be plugged into a GUI application. To use these built-in UI widgets effectively, the application had to be built in accordance with the MVC metaphor. Let’s take a look at the conceptual diagram of a Smalltalk-80 MVC app.

Conceptual diagram of MVC in Smalltalk-80 (from Krasner & Pope)

All objects in Smalltalk communicate with each other via messages. Think of messages as a way to invoke methods in an object.

At first glance, the MVC conceptual diagram seemed a little strange. The multitude of arrows indicated more acquaintances than I’m used to seeing in an MVC diagram. Model-View and Controller-Model dependencies ran both ways. The second interesting aspect was that user input goes directly to the Controller. This is a significant change as we generally expect users to interact with UI widgets in the View. In Smalltalk-80, it looks like the raw keyboard and mouse input is fed directly to the Controller. Let’s take a quick look at how the MVC metaphor is supported in Smalltalk-80.

MVC Classes in Smalltalk-80

There are three abstract classes called Model, View and Controller. All concrete implementations of model, view and controller have to subclass these abstract superclasses. Let’s take a look at the classes (this is an abbreviated description – see Krasner and Pope for more detail).

The Model Class

The abstract superclass Model implements generic model behavior. It implements a dependency maintenance mechanism. Views can register with concrete models to become dependents and receive update messages.  When a concrete model sends itself a changed message, an update message is sent to all of its dependent views automatically. This is an implementation of an Observer Pattern. The concrete model, being the subject in the pattern,  doesn’t explicitly know about its views.

The View Class

The abstract superclass View implements generic view behavior. The built-in UI Widgets subclass View (e.g. StandardSystemView and TextEditorView). Views can be nested to develop a complex user interface. For example, the StandardSystemView (i.e. window) contains a sub view (child view) called TextEditorView in the figure below.

A text editor built using UI widgets showing nested views and corresponding controller (from Krasner and Pope)

Each view can have one model and one controller. The built-in UI Widgets have a pre-specified default controller class to implement its default behavior (TextEditor is the default controller for the TextEditorView UI widget). To instantiate a built-in UI Widget, you need to set its model and open its window. The UI Widget will then initialize its default controller with the same model instance and register with the model as a dependent. When a window is closed, its nested views are released. When a view is released, it removes itself as a dependent form the model. All this plumbing and initialization is part of the generic code in the superclass View. If you want a UI widget to have custom behavior, you can set a custom controller for it.

The Controller Class

The abstract superclass Controller implements generic controller behavior. Each controller has a reference to one model, one controller, and a global variable called Sensor that provides an interface to the user-input devices for mouse, keyboard, and cursor interactions. The Controller superclass implements generic behavior to determine if a concrete controllers’ corresponding view has mouse focus. If the corresponding view has focus, then its controller maintains control of all user input.

The controller needs to have an explicit reference to its view because it queries the view to determine if the mouse cursor is within the views’ display rectangle. This is non-trivial as the nested view hierarchy has to be traversed. Controllers need to be well behaved, as they grab and release user input. If a view is not interactive, then its controller is a NoController instance that doesn’t take control of user input.

It is significant that only controllers, and not views, receive user input. There is a clean separation of concerns as views’ only display model data.

Key Features of the MVC implementation in Smalltalk-80

• Each built-in UI Widget is a view.
• Views can be nested.
• Each view has a corresponding controller.
• The controller queries its view to determine if it has focus to receive user input.
• The active controller (whose view has focus) receives user input.
• Controller can update the view (UI Widget) based on user input.
• Controller modifies the model based on user input.
• Views update themselves using observer synchronization with the model.

Comparing Smalltalk-80 UI Widgets (views)  to Flash Components

UI Widgets in Smalltalk-80 are built according to the MVC metaphor. UI Widgets represent the view in the MVC triad. In addition to the pre-built UI widgets, Smalltalk comes with a number of controller and model classes that can be matched with UI widgets (views) to provide default behavior. For example, there is a subclass of Model called TextHolder that can serve as the model for the TextEditorView UI widget and its corresponding default controller TextEditor. Default component behavior can be overridden by plugging in a custom controller to the UI Widget.

ActionScript built-in components do not provide this much abstraction. Unlike Smalltalk, users interact directly with UI Components in Flash. How the component responds to user input is not abstracted out to a public controller class – the default action is encapsulated and implemented within the component itself. However, all AS3 components implement the IEventDisptacher interface.  We can register with a UI Component to receive the same user events that the component acts on. There are several ways to prevent default behavior if the component allows it.

Unlike UI Widgets in Smalltalk, much of the controller functionality is implemented by Flash components. Essentially, the component handles its own logic and state. For example, let’s examine the class hierarchy of the AS3 Button Component.

AS3 Button Component Class Hierarchy

Package	fl.controls
Class	public class Button
Inheritance	Button  LabelButton BaseButton UIComponent Sprite DisplayObjectContainer InteractiveObject DisplayObject EventDispatcher Object
Implements	IFocusManagerComponent

All AS3 components subclass UIComponent whose parent classes provides functionality to manage focus, receive user events in addition to the traditional view responsibilities of coordinate transformations and nested view management.

This is the interesting dilemma when implementing the classic MVC pattern in AS3. Because UI components implement much of traditional controller functionality, does the controller have any utility in an AS3 MVC application. The best way to answer this question is to develop a simple classic MVC app in AS3.

A simple Smalltak-80 MVC application

Krasner and Pope implement a simple example application in their article to demonstrate the MVC paradigm. The application is a simple counter. The model stores the value of the counter. There is a top view (window) and three sub views: a view that displays the value of the counter (a text display area), a view that increments the counter (button), and a view that decrements the counter (button).

Counter example application showing view hierarchy

I’m going to develop the counter application in ActionScript using built-in Flash components while remaining true to the classic MVC implementation in Smalltalk-80. The first step is to explore support for the MVC paradigm in ActionScript.

Support for classic MVC implementation in ActionScript 3.0

Unlike Smalltalk-80, there is no explicit support for MVC development in ActionScript 3.0. That being said, let’s compare the key features of MVC implementation in Smalltalk-80 to what is available in AS3.

Let’s implement the Counter application based on these accommodations. I’m not implying that this is the best way to implement an MVC architecture in AS3. The intent is to explore the good, the bad and ugly of appropriating a classic MVC architecture into an AS3 application.

Implementing the Counter application in ActionScript 3 (using V3 components)

The first step is to define the Model, View and Controller abstract superclasses. The first limitation is that AS3 does not support abstract classes. However, as UI Components implement much of the required default behavior already, we can define pure interfaces. The model needs to implement IEventDispatcher and the controller needs to define a handler that can receive user events. All built-in components subclass UIComponent and we can consider it as the superclass for views.

The AS3 implementation showing class relationships

CounterView is the top level view that contains the DisplayView, IncrementButtonView, and DecrementButtonView. DisplayView subclasses the Label component and registers with CounterModel to receive CHANGE events when the counter value is updated. DisplayView doesn’t respond to user input and doesn’t have a corresponding controller. In contrast, IncrementButtonView and DecrementButtonView subclass the Button component and respond to user gestures. Each button view registers a corresponding controller to receive CLICK events. The controllers modify the model based on these events.

Although model – view relationships are similar to the classic Smalltalk-80 MVC implementation, the controller relationships are radically different. The controllers essentially observe the views to catch user events. In addition, controllers don’t need to have an explicit reference to their views either. The event object that is passed to the controller when the event occurs has a reference to the UI component targeted by the event.

Take a look at the implementation in AS3 and inspect the classes. Flash V3 components are not available by default in Flex/Flash Builder. Therefore, the components have to be brought over from Flash CS3 in a swc file. This post by Josh Tynjala explains the process.

The AS3 implementation of the Counter showing the package hierarchy and classes

The Good, bad and ugly of the ActionScript implementation

The big difference in the AS3 implementation concerns the role of the controller. Flash UI components have taken over the role of the classic controller and relegated it to observe corresponding UI components. Does the controller play its intended role in the MVC triad, which is to serve as a strategy for handling user input? As UI components handle their own user input, the controller has become a strategy for handling change in UI components. Is there a big difference?

The good aspects

• Separated presentation is maintained.
• Controller is a strategy for handling user input (or is it?).
• Controller is essentially a command object that can be invoked by multiple views.

The disconcerting aspects

• Controller is essentially a command object – it makes sense if multiple views invoke the same command. Otherwise it may as well be tightly bound to its view.
• Event bubbling in complex nested views obsoletes the necessity to have a controller for each UI component.
• Flex and data binding may offer simpler ways of implementing separated presentation.

Form your own conclusions

The intent of this post was to lay some groundwork for the upcoming presentation patterns in this series. Exploring the utility of the classic MVC paradigm with a concrete example made a lot of issues explicit. There is a lot of heated discussion regarding the role of MVC in contemporary development with rich components. Bill posted Is MVC Obsolete? Flex, ActionScript 3.0 and the MVC Design Pattern on the issues raised by Brian Lessig’s MVC as Anti-Pattern article sometime back. The spirited discussion that followed is very relevant to this post.

References

• A cookbook for using the model-view controller user interface paradigm in Smalltalk-80 by Glenn Krasner and Stephen Pope.
• Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC) by Steve Burbeck.
• Inside Smalltalk Volume II by Wilf Lalonde and John Pugh.

Truckin' thru MVC

Looking at the design patterns inside MVC should help you see what we mean by the term “pattern.”

The phrase, the design patterns inside MVC is where the trolly may have jumped the tracks.

I believe that the design pattens that GoF are talking about in reference to the MVC are actually classes that have certain design pattern features found in patterns such as Strategy, Observer and Composite, but they are not referring to the entire pattern. Many design patterns have classes or operations that reflect the entire design pattern. For example, the Template Method pattern has a function (a method) that is a called a template method. So you can have just a single method that describes an entire pattern. Likewise the Stratey pattern contains an interface called strategy, the Observer has an interface known as, observer and the Composite pattern has a concrete class named composite. What makes the MVC valuable is that it contains elements of these other patterns to aid in understanding design patterns in programming. In and of itself, it is good for certain applications, but only to a limited extent. The point is that GoF use MVC to,

LLUSTRATE how classes and objects work interdependently to accomplish a task that can be reused and easily changed.

Another source of possible confusion is the figure on page 5. The different graphs and charts are labeled views and the percentages at the bottom are labeled model. It is used to explain the role of the model and view in the MVC. So naturally, in situations where you have multiple views for a single or multiple data sources, you think of MVC. However, that exact same figure is found on page 293 in the chapter on the Observer pattern, but the charts and graphs are labeled observers and the data source, subject. The lines between the different parts are identical in both illustrations—including the labels on the lines. On pages 317-329 of our book, you’ll find where we used the charts and tables to show how the Observer design pattern can be usefully adopted to generate different views from a single data source. In the context of the GoF book, the illustration on page 5 is to show how different classes interact and is a useful tool for an illustration—and really nothing more. Figure 1 shows how users changed a demonstration into something it was not intended to be:

Figure 1: What the MVC is (left) and how it has been used (right).

Often, critics beat up the MVC for not being a one-man band when all it was meant to do was to play the cornet.

The True Value of the MVC

Because the MVC was the last pattern I spent any amount of time with, I looked at it with a different perspective. I knew of several different patterns that could be used to accomplish what the MVC does, and so I didn’t consider the MVC as the be-all and end-all of design patterns. It is most valuable when used as GoF intended—a leaning tool. After working through an example, I found the circular communication between the Model, View and Controller very educational. As a device for learning how event dispatching works, I can think of no better. Knowing how classes communicate is essential to understanding design patterns, and for that, the MVC does an excellent job. I truly believe that was the intention of GoF and nothing more. They say as much.

After going over Chapter 12, in our book (one that Chandima did), I learned far more about inter-class communication than I believed was left to learn. (By the way, if you found this series useful, you’re going to be amazed by what Chandima has done with MVC in Chapter 12, both in ways of MVC use and as an explanatory tool for inter-class communication.) My own conclusion is that everyone interested in design patterns needs to spend some time with the MVC to better understand design patterns in general. However, I see it as a fairly limited tool that does a very good job of just a few things and other design patterns are better suited for most tasks. At the same time, I do not think it is the villain some have portrayed it to be, and it has often been criticized for not being an apple because it is an orange. By the same token, I don’t think it’s the Swiss Army Knife of design patterns. It is what it always has been in the context of design patterns—an illustration of interacting objects.

Truckin' thru MVC

Adding an Interface for the View

Before adding another view, I wanted to add an interface so that I could use the same Model and Controller classes. The changes are minimal in the revised View classes, and I changed the Client so that it could more easily request any view the user would like. Since you have all of the details about how the MVC works in Parts I-III, I’ll get right into the interface.

In looking at the View class in Part III, you can see that the class has only two methods. By putting them into an interface, we can program to the interface instead of the implementation. That means that as long as the same interface is used, you can use the same Model and Controller without any changes at all. As usual, interfaces are fairly short, and this one is no exception.

1
2
3
4
5
6
7
8
9
10
11

package
{
	import flash.display.Sprite;
	import flash.events.Event;
 
	public interface IView
	{
		function createView(vessel:Sprite):Sprite;
		function update(e:Event):void;
	}
}

Before continuing, click the Play button to test both compasses that have their roots in that interface. (compi?)

The Model and Controller classes are identical for both compass examples. Read on to see how easy it is to add views.

Because we now have an interface for the View, we need to update the original View class so that it implements the IView interface. The name of the View classes need to be unique; so the name has been changed from View to ViewAnalog. Likewise, the createAnalog() method has been given the more general name, createView() in line with the more general task of the method.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

package
{
	import fl.controls.Slider;
	import fl.events.SliderEvent;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class ViewAnalog implements IView
	{
		private var model:Model;
		private var controller:Controller;
		private var base:Sprite;
		private var compassRose:Sprite;
		private var pointer:Sprite;
		private var slider:Slider;
 
		public function ViewAnalog(model:Model, controller:Controller, vessel:Sprite)
		{
			this.model=model;
			this.controller=controller;
			base=createView(vessel);
		}
 
		public function createView(vessel:Sprite):Sprite
		{
			//add compass rose and needle
			compassRose=new CompassRose();
			compassRose.x=250,compassRose.y=250;
			vessel.addChild(compassRose);
			pointer=new Pointer();
			pointer.x=0,pointer.y=0;
			compassRose.addChild(pointer);
 
			//**add slider
			var slideHolder=new Sprite();
			vessel.addChild(slideHolder);
			slider=new Slider();
			slider.maximum=360;
			slider.width=slider.maximum;
			slideHolder.addChild(slider);
			slider.x=(250) - (slider.width/2);
			slider.y=20;
			slider.addEventListener(SliderEvent.CHANGE, controller.newDirection);
 
			return compassRose;
		}
 
		public function update(e:Event):void
		{
			pointer.rotation=model.getDir();
		}
	}
}

As you can see, it’s almost identical to the original View class. Now for the payoff of loose coupling. Instead of an analog compass, this next one is a retro-digital compass. With a black background and green text, it looks like the old monitors with black screens and green output. Placed next to the analog compass, you can see the same exact data in a wholly different framework. Figure 1 compares the different views with the same data:

Figure 1: Adding new views is easy with MVC

The following listings shows the changes that were made. Note that instead of using MovieClip objects for display, this next view uses a Shape for the background and a TextField and TextFormat for the value state in the Model. However, both are placed in the vessel Sprite and work just fine. The same Slider with the same code is reused except instead of changing the rotation, the value is placed in a TextField object.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

package
{
	import fl.controls.Slider;
	import fl.events.SliderEvent;
	import flash.display.Sprite;
	import flash.events.Event;
	import flash.text.TextField;
	import flash.text.TextFormat;
	import flash.display.Shape;
 
	public class ViewRetro implements IView
	{
		private var model:Model;
		private var controller:Controller;
		private var base:Sprite;
		private var slider:Slider;
		//Instantiate text field and format
		private var txtFld:TextField=new TextField();
		private var format:TextFormat=new TextFormat();
 
		public function ViewRetro(model:Model, controller:Controller, vessel:Sprite)
		{
			this.model=model;
			this.controller=controller;
			base=createView(vessel);
		}
 
		public function createView(vessel:Sprite):Sprite
		{
			//Create backdrop using a Shape
			var crt:Shape=new Shape  ;
			crt.graphics.beginFill(0x000000);
			crt.graphics.lineStyle(0,0x000000);
			crt.graphics.drawRoundRect(100,60,300,50,6);
			crt.graphics.endFill();
			vessel.addChildAt(crt,0);
 
			format.color=0x00ff00;
			format.font="OCR A Std";
			format.size=32;
 
			txtFld.defaultTextFormat=format;
			txtFld.x=220;
			txtFld.y=70;
			//Set default value to 0 so that
			//it does not display null--NaN
			txtFld.text=0;
			vessel.addChildAt(txtFld,1);
 
			//add slider
			var slideHolder=new Sprite();
			vessel.addChild(slideHolder);
			slider=new Slider();
			slider.maximum=360;
			slider.width=slider.maximum;
			slideHolder.addChild(slider);
			slider.x=(250) - (slider.width/2);
			slider.y=20;
			slider.addEventListener(SliderEvent.CHANGE, controller.newDirection);
 
			return vessel;
		}
 
		public function update(e:Event):void
		{
			txtFld.text=model.getDir();
		}
	}
}

Finally, the Client has to be changed a bit so that selecting one view or another is simple to do. (You can get fancier if you like and set up a UI selection.) The following listing shows the Client.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var model:Model;
		private var view:IView;
		private var controller:Controller;
 
		public function Client()
		{
			setMVC("r");
		}
 
		private function setMVC(viewType:String):void
		{
			model = new Model();
			controller=new Controller(model);
			switch (viewType)
			{
				case "a" :
					view=new ViewAnalog(model,controller,root);
					break;
				case "r" :
					view=new ViewRetro(model,controller,root);
			}
			model.addEventListener(Model.UPDATE, view.update);
		}
	}
}

As far as I can see, the MVC fulfills exactly what GoF had intended for it to do—illustrate how by loosening up classes, updating and adding new elements is easy. While I’ve been busy with OOPSLA and work, it took me a good deal of time to develop the original MVC. However, when it came to updating the program, I was able to do it quite quickly. If you’d like to download the entire set of files, click the download button that Barbara Parkman send us.

Make Your Own View

To really understand how the MVC works, you will find it helpful to create your own View for this program. Just add any kind of view you want, from simple to elaborate, and have it display data from the Model. There’s nothing you can break, and it will demonstrate how useful Design Patterns are when adding new elements to a program. In fact, we can make it into a Golden Lunch Bucket Contest if enough of you are interested. Enjoy!

Truckin' thru MVC

Taking Control

In Part II of this series on the MVC, we saw how we could separate the Model (data provider) from the View (a representation of the Model’s data—a graphic compass.) The process was simple enough, especially since all we needed from the Model was a value between 0 and 360. We made it even simpler by using constants with cardinal directions. In this final piece of the MVC puzzle, we’re adding a Controller class. The Gang of Four state that the

…Controller defines the way the user interface reacts to the user input

The UI for the controller is a Slider component set up with values ranging from 0 to 360. The View class instantiates the Sldier with Slider change events sent to the Controller class. In turn the Controller sends the Slider values to the Model, which updates its current value. The update is sent to the View class which rotates the compass needle.

So as not to lose sight of why we’re going through all this trouble, keep in mind that by decoupling the model, view and controller we can increase the flexibility and reuse of the program. In this post, we’ll see how we can create an analog compass, and in Part IV of this series how we can add different kinds of views that display the same information. To get started, take a look at the revised Analog Compass using a Slider for changing the position of the compass needle. Slide the Slider thumb-press along the top left and right. (Also, try pressing and holding down the left and right arrow keys.)

As you can see, the compass needle moves as soon as the Slider stops and the thumb-press is released. You could get a livelier motion using a few more lines of code, but for now, we’ll keep it simple and focus on the design. Figure 1 shows what you will see.

Figure 1: Analog Compass controlled by Slider and Arrow Keys

The compass rose and the needle are both instantiated as Sprites in the program but were created in the Library as MovieClip classes. No Timeline commands were required so instead of treating them as MovieClips, both could be used as Sprites. You could do the same thing with externally loaded SWF files placed into dynamically created MovieClip classes.

We Need to Talk

For everything to work, the classes need to talk. A Client class uses the Model, View and Controller classes that in turn communicate with one another. Figure 2 shows the communication pattern the MVC classes. The Client instantiates all three classes and sets an event listener to a Model instance to listen for an update notice and to invoke a View method when an update occurs.

Figure 2: MVC Communication

As you can see in Figure 2, the Model and View keep each informed of states and the Controller sends the Model changes made by the user who is either dragging the Slider control or pressing the left and right arrow keys.

The Client

Like all Client classes, this class makes requests. However, rather than communicating with a single class or multiple classes through an interface, this Client uses all three—Model, View and Controller. One of the most interesting elements I found in fiddling around with the MVC is the way it uses events and event handling. The Client sets up a Model event listener that fires an update method in the View instance.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var model:Model;
		private var view:View;
		private var controller:Controller;
 
		public function Client()
		{
			model = new Model();
			controller=new Controller(model);
			view=new View(model,controller,root);
			model.addEventListener(Model.UPDATE, view.update);
		}
	}
}

Notice that both the View and Controller instances hold a reference to a model instance in their constructors. Further, note the use of the root property. When ActionScript 3.0 came along, I gave up using any reference to root because I associated it with the old ActionScript. However, had I bothered to read about root in the ActionScirpt 3.0 Reference, I would have found that it is a new root. It’s very handy for placing objects where you want them to go.

Model

As you can see and no doubt expected, the Model contains a getter and setter for the value to be used by the rotation value of the compass needle. However, much more interesting, is how the EventDispatcher is employed. In Chandima’s work, he uses both the IEventDispatcher and EventDispatcher, and Bill and Anthony use the EventDispatcher. It allows you to make an event in your object that can be fired when called upon. The notify method may remind you of the Observer Design Pattern, and indeed it should. When changes in state occur in the Observer, it notifies subscribers of the changes.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package
{
	import flash.events.EventDispatcher;
	import flash.events.Event;
 
	public class Model extends EventDispatcher
	{
		public static const UPDATE:String="inform view";
		private var dirNow:Number;
 
		public function setDir(dirNow:Number):void
		{
			this.dirNow=dirNow;
			notify();
		}
 
		public function getDir():Number
		{
			return dirNow;
		}
 
		protected function notify():void
		{
			dispatchEvent(new Event(Model.UPDATE));
		}
	}
}

The static construct UPDATE is a string with any value. (I used “inform view” to remind us that it’s the View instance that uses the data from the Model.) When the direction is re-set by a call to setDir() by the Controller, it informs the View of the change. The static attribute assigns the constant to a member of the class rather than of an instance of the class. In that way you can use a self-reference to the event through Model.UPDATE within the Model class.

View

The View class probably should have an interface in the form of either an abstract class or interface. However, we’ll save that for Part IV of the discussion of MVC. The reason for an interface is that we’re likely to implement more than a single view. (The Gang of Four show three different possible views in their brief MVC discussion.) For now, we’ll just settle for a good understanding of the role of the View class in the MVC.

The view refers to the view of the data from the model. The Model data is set through the Controller sending it values from the UI. The View is notified when the data changes and requests the new data by a call to the Model’s getter. The View displays that data any way it wants, and in this case its through an analog compass. The values 0 to 360 are passed to the rotation property of a Sprite object representing the compass needle.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

package
{
	import fl.controls.Slider;
	import fl.events.SliderEvent;
	import flash.display.Sprite;
	import flash.events.Event;
 
	public class View
	{
		private var model:Model;
		private var controller:Controller;
		private var base:Sprite;
		private var compassRose:Sprite;
		private var pointer:Sprite;
		private var slider:Slider;
 
		public function View(model:Model, controller:Controller, vessel:Sprite)
		{
			this.model=model;
			this.controller=controller;
			this.base=createAnalog(vessel);
		}
 
		function createAnalog(vessel:Sprite):Sprite
		{
			//add compass rose and needle
			compassRose=new CompassRose();
			compassRose.x=250,compassRose.y=250;
			vessel.addChild(compassRose);
			pointer=new Pointer();
			pointer.x=0,pointer.y=0;
			compassRose.addChild(pointer);
 
			//add slider
			var slideHolder=new Sprite();
			vessel.addChild(slideHolder);
			slider=new Slider();
			slider.maximum=360;
			slider.width=slider.maximum;
			slideHolder.addChild(slider);
			slider.x=(250) - (slider.width/2);
			slider.y=20;
			slider.addEventListener(SliderEvent.CHANGE, controller.newDirection);
 
			return compassRose;
		}
 
		public function update(e:Event):void
		{
			pointer.rotation=model.getDir();
		}
	}
}

The Slider object has an event listener that reacts to changes in the Slider’s value property. When it changes, it calls a Controller method that passes on that value to the Model. That change sets off an update event that fires a View function to move the pointer to the changed position of the Model.

Controller

Finally, we come to the Controller. It’s job is to define the way the user interface reacts to the user input. In this case, it waits for a SliderEvent and uses the Slider.value (e.target.value) to update the Model’s current value. That’s it! It’s job is very simple.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
	import fl.events.SliderEvent;
 
	public class Controller
	{
		var model:Model;
 
		public function Controller(model:Model)
		{
			this.model=model;
		}
 
		public function newDirection(e:SliderEvent):void
		{
			var dirNow=e.target.value;
			model.setDir(dirNow);
		}
	}
}

Going Next Door Around the World

Back in the old days, hackers idea of a good time was to tap into the phone system and see if they could call the house next door by routing the call around the world. With this example of the MVC, that may have seemed to be what we did. Starting with the View, the program sends a message to the Controller, which changes the state of the Model which is used by the View to rotate the compass needle. Of course, the purpose is not to convolute a perfectly simple operation but rather to create a design that is wide open for change and update. The purpose of the MVC as used by the Gang of Four is to help you see what we mean by the term “pattern.” So rather than looking for the shortest distance between two points, you should do as GoF suggests—look to see how pattern is used. In the next installment, we should be able to see it even more so as we add a new view to the MVC. (The wait for Part IV will not be long because design patterns are easy to update and change, remember?)

Truckin' thru MVC

Straws and Stacks: MVC as a Reality sui generis

Years ago in an introductory sociology course, I became acquainted with the concept of a reality sui generis. Some of you may have come across the term elsewhere with different meanings in different contexts. Biology, law and political science have their contextual uses of the term, but the one we’re using here is the one from sociology. Emile Durkheim employed the term in his work, Suicide, to describe a social fact. For Durkheim, a social fact is a phenomenon of social behavior not reducible to its component parts. A bureaucracy is an organizational arrangement that we think of independent of those who actually make up the bureaucracy. It is a reality sui generis—a reality in and of itself. So, we can study phenomenon like families, groups, and organizations as being separate from the people who make them up. Each has characteristics that cannot be seen in the individuals.

To help us understand the concept, we were given the example of a stack and the individual straws that make up the stack. Straws and stacks have wholly different features even though one exists because of the other. By the same token, the MVC, while made up of objects, has characteristics independent of those objects. So, we might envision the MVC as a reality sui generis.

Having noted the different characteristics of straws and stacks, the characteristics of the straws can alter the stack. A stack made of shards of glass is certainly going to be different than one made of wheat or alfalfa straws. So, yes, the components do make a difference. An MVC can be made of different component objects, resulting in different capabilities, is still an MVC.

Comfort Level of Abstraction

For too long I remained in a stultifying comfort level in programming. After tip-toeing into OOP, I was quite content with my algorithms and syntaxes, but other than thinking this was cooler than procedural programming, I never really left the entry level of OOP. Therefore, I never saw the advantages of design patterns or architectures outside of procedural steps. I could always learn a new algorithm or dig deeper into the syntax giving myself the illusion of making progress.

The MVC can be a way to step up and out of the statement level of abstraction. Once we realize that a class can be a reality sui generis—an object—the next level of abstraction asks us to think of design patterns as a reality sui generis. Ironically, the MVC begins by breaking up a single entity that combines the model, view and controller and restructures them for better use. You can think of this as breaking up a great big class and creating smaller objects to add flexibility to programming. (Imagine a giant straw being chopped up to make a stack—the straw can never be a stack by itself.)

In that process, the MVC clearly defines the relationships between the objects. That’s why the first chapter of GoF spends so much time on relationships. It is not about algorithms and syntaxes for a reason. The MVC is initially used as a heuristic* device to show readers how objects relate to each other. GoF describe relationships in the MVC in terms of the general problem:

…decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others.

That means that you can introduce new elements to a program by attending to the relationships between objects. Because the objects are decoupled, a change in one will not break the other or even require that you do anything to the related objects. However, you do need to think of the relationships between the objects.

*By heuristic, I’m referring to a strategy to help the reader understand design patterns—not the way the term is used in computer engineering or computer programming.

The Model and View Relationship

For the time being, forget about the Controller. We’ll just look at the Model and View. On Page 5 of their book, GoF show a simple example of three variables with different assigned values labeling it as the model. Three different images display the values in the form of a table, bar chart and pie chart. These are the views of the data in the model. So all that the view is doing is presenting the values generated in the model. It doesn’t matter how much data there is in the model or its data values, it just models the values that the view uses to present it in any way it wants.

The relationship between the model and view is a two-way one. The model tells the view to update itself, and the view reads the data in the model. That’s it! The MV relationship is simple. We’ll get to the role of the controller, but for now, what you need to know is that the MVC first identifies and then separates the three elements that makes up the model, view, and controller.

Programming a Compass

Now that we have an idea of the MVC, the best place to start is with an UnMVC. That is, we’ll start with a program that is in a single class and then break it up into an MVC. For the example, we’ll use a compass. The compass is made up of two movie clip classes. One is a compass rose that serves as a background, and the other is a compass red and gray needle. The needle is positioned in the middle of the compass rose using its center as a pivot point. The compass rose center point is the center of the rose and not the upper-left hand corner. One MovieClip has the Class name, CompassRose and the other Pointer. The following program displays the compass with one of four selected directions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package
{
	import flash.display.Sprite;
 
	public class UnMVC extends Sprite
	{
		//Model
		private const NORTH:uint=360;
		private const NORTHEAST:uint=45;
		private const EAST:uint=90;
		private const SOUTHEAST:uint=135;
		private const SOUTH:uint=180;
		private const SOUTHWEST:uint=225;
		private const WEST:uint=270;
		private const NORTHWESTT:uint=315;
		private var currentDirection:uint;
		//View
		private var compassRose:Sprite=new CompassRose();
		private var pointer:Sprite=new Pointer();
 
		public function UnMVC()
		{
			compassRose.x=200,compassRose.y=200;
			addChild(compassRose);
			pointer.x=(compassRose.x),pointer.y=(compassRose.y);
			//Controller
			pointer.rotation=SOUTHWEST;
			addChild(pointer);
		}
	}
}

Figure 1 shows what you can expect to see when you test the program:

Figure 1: Compass needle points to value in Model

Now, you may be thinking that the little program is too tiny to be an MVC. Of course, it’s not an MVC because it’s all in a single class, and that’s why it’s named UnMVC. However, you can see all of the elements of the MVC in the comments.

Breaking Up Is Hard to Do: From UnMVC to MVC

The first step is to break up the UnMVC class into Model and View classes. We’ll also pick up a Client class to launch the whole thing. Before we do that, though, take a look at page 429 [Figure 12-1] of our book. Chandima has made a very clear illustration of the relationships between all three elements of the MVC. Further, he shows their flow sequence. For now, though, we’ll just be focusing on a single relationship—how the Model provides data to the View. The manner in which this can be done can take many forms, but in the example, the View simply requests the Model for data with the Model deciding which direction to provide. The Client acts something like a Controller, but just treat it as a Client for now. The following three scripts are the first steps in breaking up the UnMVC into a MVC.

First, the Model just has the data to be used.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package
{
	import flash.display.Sprite;
 
	public class Model extends Sprite
	{
		private const NORTH:uint=360;
		private const NORTHEAST:uint=45;
		private const EAST:uint=90;
		private const SOUTHEAST:uint=135;
		private const SOUTH:uint=180;
		private const SOUTHWEST:uint=225;
		private const WEST:uint=270;
		private const NORTHWESTT:uint=315;
		private var currentDirection:uint;
		private var currentDirection:uint;
 
		public function Model()
		{
			setDir(NORTHEAST);
		}
 
		public function setDir(currentDirection:uint):void
		{
			this.currentDirection=currentDirection;
		}
 
		public function getDir():uint
		{
			return currentDirection;
		}
	}
}

Whenever the Model is instantiated, it fires a function to set the current value. This value is picked up by the View using a getter function in the Model. So the request comes from the View as illustrated in Figure 2.

Figure 2: View requests data from Model

In the following View listing, the constructor function has been omitted, and all of the work is done by calling methods from within the View or by calls to the Model.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package
{
	import flash.display.Sprite;
 
	public class View extends Sprite
	{
		private var model:Model=new Model();
		private var compassRose:Sprite=new CompassRose();
		private var pointer:Sprite=new Pointer();
 
		public function setView()
		{
			compassRose.x=200,compassRose.y=200;
			addChild(compassRose);
			pointer.x=compassRose.x,pointer.y=compassRose.y;
			pointer.rotation=model.getDir();
			addChild(pointer);
		}
	}
}

Before going on, I want to quickly mention Miško Hevery’s post on not having the constructor function doing any real work. Anything more than field assignments in constructor functions is considered a flaw in writing testable code. I believe that this rule is suspended for the Client class, but as I’ve been cautiously removing any real work from constructors, I’ve found my code far easier to debug and reuse. We need to have a separate post on the issue of constructors using ActionScript 3.0 examples, but in the meantime take a look at Miško’s post on constructors.

Finally, We’ll use a Client class that launches the Model and View classes and places the compass on the stage pointing East this time.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var view:View=new View();
		private var model:Model=new Model();
 
		public function Client()
		{
			view.setView();
			addChild(view);
		}
	}
}

As a start in understanding the MVC, we began with a single class that contained the elements of an MVC. It was broken apart to reveal the Model and View by placing them in separate classes. However, the important information to take away from this is the relationship between the Model and View classes. Because we have no Controller object, we have no way to change the View independent of the Model. In cases where the Controller can add data directly to the View, the View needs to inform the Model so that it can change its data. For now, though, we just have the View class requesting data from the Model and using it to change the direction of the compass pointer.

In the next and last post of Truckin’ Through ActionScript 3.0 MVC, we’ll finish up the MVC by adding a Controller module and consider replacing the class objects with design pattern objects.

Truckin' thru MVC

MVC in a Nutshell: The Great Decoupler

To get started, GoF show the MVC to be three distinct components in what they call a a triad of classes. As such, they discuss its elements in terms of objects. The application object is defined by the Model, the screen presentation by the View and the way the way the user interface reacts to the user input by the Controller. Prior to MVC, the application, its appearance on the screen and the UI were grouped together in a single class. By decoupling the objects into separate units, the MVC loosens the relationship following a key good practice. (I used to cram them all together in a single class thinking that I was tightening up my code—how dumb was that?) As a first image of the MVC, then, think of it as a tool to loosen up code.

Metallurgy and Structural Engineering

Every now and again, I see the perp walk of a contractor who’s been arrested for using inferior materials on a public structure. In one case, the contractor increased his profits by using cheaper steel beams in a bridge he built. At the trial the prosecution proved that the beams were substandard by the expert testimony of a metallurgist. The metallurgist compared the beams used in the bridge with those that met the building standards and found the ones used by the contractor to be substandard.

Structural engineers will tell you that the strongest structure in construction is a triangle. That’s why you see so many triangles in bridge structures. While studying at Cambridge, I visited the wooden bridge at Queen’s College known as the Mathematical Bridge—lots of triangles in its structure. The bridge was originally built in 1749 and then rebuilt in 1866 and and again in 1905. Given that history and the fact that it’s made of wood says more for the structure than it does for the building materials.

Figure 1 shows two different bridge structures. The top structure shows the bridge held up by beams arranged in a square that fail when too much pressure is placed on the bridge. The bottom structure shows triangles used to hold up the bridge withstanding pressure:

Figure 1: Structure is independent of the materials that make up the structure

If you look at a problem from the viewpoint of a structural engineer, you tend to see how the different elements relate to one another. If you look at the problem from the view point of a metallurgist, you tend to look at the composition of the materials. Think of the beams as ActionScript 3.0 and algorithms, and think of the design patterns and the MVC as the structures arranging the beams.

Ever since the advent of ActionScript 3.0, a lot of us have been very happy with it as the basic construction material of our programs. Earlier versions of ActionScript were unsatisfactory in many ways, and while ActionScript 3.0 is far from perfect, it is light years better than the original. So unlike the contractor who is being frog walked into court for using inferior materials, we’ve got very good materials. The problems arise when developers fail to use good structures. Even the best materials will fail without good structure as Figure 2 shows.

Confusing Materials and Structures: The Drunk’s Search

An old joke tells the story of a drunk who has dropped his keys in a dark doorway. He staggers out to a street light and proceeds to look for them. A police officer comes by and asks the drunk what he’s doing. The drunk explains that he has dropped his keys in the dark doorway and he’s looking for them. Confused, the police officer asks, “Well why are you looking here under the street light instead of the doorway where you dropped them?” The drunk looks up and says, “Because this is where the light is!”

The point of this story is that we often look to ActionScript, it’s syntax, methods, events, and properties because we understand it better. Instead of looking at the structures of our programs, we focus on getting something to work because for many of us, ActionScript is where the light is!. We’ve spent years trying to understand and use ActionScript 3.0, and we tend to define problems and solutions in terms of that understanding. The MVC is a great place to break off from our focus on the materials of ActionScript 3.0 and to re-focus on the structures we are putting our ActionScript 3.0 into. By breaking up the application, screen presentation and user interface, we have to re-think what we’re doing with our code. We have to use it differently.

Now, lest we think that we can work with structure while ignoring materials, let me disabuse you of that notion. The corrupt contractor who uses inferior materials (algorithms) is going to build an inferior bridge, no matter how good his structure is. It’ll hold up, but sooner or later, the materials fall apart along with his well-structured bridge. Likewise in programming, we must attend to our algorithms, but like the language itself, they must be placed in the best possible structure.

To give you an example, PHP is not a typed language—the data are weakly typed. Yet you will find plenty of PHP design patterns. In fact IBM sponsored a whole series of PHP design patterns. I’ve never understood how you can follow one of the first principles of design patterns, type to an interface; not an implementation, using PHP. Given that PHP and ActionScript 3.0 are different materials is only important insofar as syntax and symbols require different ways to implement design patterns. The classes in the design patterns have the same relationship, however. So if you understand the design patterns in one, it’s not so difficult to understand them in the other. In the same way that your can use bamboo or steel I-beams in bridge construction with the same structure, the details of using the different materials vary independent of the structures.

Selecting Design Patterns for the MVC

In the next installment of this discussion of the MVC, I’d like to look at the possible design patterns we might use. We know that to select a design pattern for a task, we must ask, What varies? However, since we are in a position to select multiple design patterns as part of a larger pattern or framework, what are the questions we need to ask and answer to accomplish a goal where we use an MVC?

The basic difference between single-core ( now known as the standard version ) and multicore is that multicore allows multiple MVC triads (multiple cores in PureMVC parlance) to be embedded inside a single application. The general recommendation is to use PureMVC multicore for all projects as it affords a lot more power in terms of developing modular applications and unit testing. However, developers who are new to PureMVC should first develop a simple single-core application first to get familiar with the framework. My previous PureMVC post describing a minimalist example will get you started with the basics. From here onwards, I’m assuming that you have a basic understanding of how the standard version of PureMVC works.

The coding differences between standard and multicore

The coding difference between the standard and multicore versions is indeed trivial. In the standard version,  there is only one PureMVC core ( MVC triad ). So, the call to access the facade and initialize the single core is as follows:

1
2

// standard version
var facade:ApplicationFacade = ApplicationFacade.getInstance();

The facade is a singleton in the standard version. The getinstance call will always return the same facade instance as should be the case when the application is restricted to only one MVC triad. In the multicore version, there can be multiple PureMVC cores. Each facade is a named singleton that represents a separate PureMVC core. To access the facade of a particular core, you must pass its name ( or key ) as an argument in the getInstance call. The key is a string that serves as the unique identifier for a particular PureMVC core.

1
2
3

// multicore version
var facade:ApplicationFacade =
              ApplicationFacade.getInstance( applicationKey );

After you access a particular core through its facade, the programming idioms for multicore are almost identical to the standard version. There are a couple of small caveats and this post by Toby Ashley has a more detailed explanation of the differences.

The conceptual differences between standard and multicore

There is no real point in having multiple PureMVC cores in an application if they are deaf and mute. The power of multicore is realized when the cores talk to each other. However, this is where multicore throws another layer of abstraction ( and an ulcer or two ) into the mix. Cores don’t talk with each other using notifications, the now familiar communication method between the model, view and controller tiers. Communication between cores can be accomplished in two ways:

1. Using interfaces.
2. Using the Pipes Utility.

It’s all about communication

Understanding multicore is really about figuring out how to plumb your application to enable cores to talk with each other. However, at this point in time, there are very few examples out in the wild. On top of that, there are hardly any non-Flex examples. The rest of this post will show how to develop a non-Flex PureMVC multicore application that uses interfaces for inter-core communication.

When multicore came out, I felt like someone had moved my cheese because I was very comfortable with the standard version. Don’t get me wrong, multicore was the next logical iteration for PureMVC and Cliff Hall has masterfully shepherded its growth. If you feel like the cheese has moved a little bit, you will like the example app. It is called “Move the Cheese” (obviously).

Move the cheese

Move the cheese is a little game – move the piece of cheese to prevent the rodents from getting to it. Don’t expect any compelling gameplay – I chose this particular scenario to exemplify the utility of PureMVC multicore.

Screenshot showing two rats moving towards the cheese.

The Flex framework examples of multicore have a modular architecture. For example, the Modularity multicore demo  ( see source ) has a main application (the shell) that loads two types of widgets: coolwidget and superwidget. Each widget has a separate PureMVC core associated with it. The shell application has a PureMVC core as well. Coding-wise, the advantage of this modular approach is the loose coupling between the application shell and the widgets as they are completely defined by interfaces. This is particularly useful in the sense that you can write some specs for the behavior of a widget, provide the IWidget interface and let a developer go his/her merry way and develop the widget. It can be plugged into the main application shell when it’s done. This is the primary advantage of multicore, it enables the development of independently functioning modules.

In a game context, each level can be a separate module that can be loaded when the player gets to that stage. This is advantageous in a resource allocation sense as well because assets are loaded only when needed. I’m taking a different approach with “Move the Cheese” ( for simplicity’s sake ). Instead of loading levels as modules, I’m going to consider the actors ( Rats in this case ) as loadable modules. The argument being that the same actor can appear in multiple levels and will be loaded as needed. Will each rat need a separate PureMVC core? How about the cheese?

Actors vs. props

Everything is happening on the stage, so let’s extend the theater metaphor. It is helpful to consider view components that need to function independently as actors on the stage; everything else is a prop. If you think a view component  needs a brain ( logic ) to figure how they need to behave ( state ), it is quite possible that it may benefit from an MVC architecture. The rats have to figure out where the cheese is located, and move towards it at a particular speed. I think that requires some grey matter ( in a figurative sense ). Coupled with the potential re-use, I argue that each rat should be a loadable module with an associated PureMVC core.

The cheese on the other hand is a prop. Yes, it is an interactive object because the user can drag it, but it doesn’t function independently (no logic and no state). It just sits there until moved – just like a prop on the stage.

The stage ( a.k.a application shell) should have a core associated with it by default because it places actors and props on stage and brokers the communication between them.

The application shell and the rat view components have PureMVC cores associated with them.

What is a PureMVC core?

It is helpful to take a step back at this point and visualize the birth cycle of a PureMVC core. All PureMVC applications do something like the following – usually in the constructor.

1
2
3

var facade:ApplicationFacade =
         ApplicationFacade.getInstance( applicationKey );
facade.startup( this );

The first statement initializes the PureMVC core ( e.g. creates the model, view and controller named singletons). In the second statement, the application passes a reference to itself to the ‘startup’ method in the facade. The application in most cases is the root view component (e.g. the document class in a Flash CS3 app, a Flex MXML application). In short, the root view component initializes a PureMVC core and injects itself into it. I couldn’t help but visualize this scenario as a snail without a shell, creating one and crawling inside it.

Birthing a PureMVC core: The snail and shell analogy.

How do cores talk to each other using interfaces?

Cores talking with each other is a bit of a misnomer. Each PureMVC core is well encapsulated like a snail that hides inside its shell. Talking depends on how much the root view component (snail body) exposes itself outside the PureMVC core. It is the view components that really do the talking between cores. The language they speak is defined by interfaces. A core that doesn’t talk is like a snail that never comes out of its shell.

The view component (snail body) needs to expose itself outside the PureMVC core (shell) to talk.

We can now get back to the application and define some interfaces.

Application specs

Now that we have thought through the application, let’s nail down some specifications. The application shell will know where the cheese is located, so it has to expose the cheese location to the rats. The rats in turn need to have a reference to the shell so that they can query the shell and get the cheese location. The application shell also takes the responsibility to place the rats on the stage and  update them at specific time intervals. So, the rats needs to expose initialization and update methods as well. Let’s write a couple of interfaces: IActor for the rats and IApplicationShell for the application.

IApplicationShell interface

1
2
3
4
5
6
7
8
9

package com.as3dp.puremvc.movethecheese.interfaces
{
	import flash.geom.Point;
 
	public interface IApplicationShell
	{
		function get cheeseLoc():Point;
	}
}

IActor interface

1
2
3
4
5
6
7
8
9

package com.as3dp.puremvc.movethecheese.interfaces
{
	public interface IActor
	{
		function setApplicationShell( shell:IApplicationShell ):void;
		function init():void
		function update():void
	}
}

Inter-core communication through interfaces implemented by their root view components

The root view component of  the application shell will implement the IApplicationShell interface and the rat view component will implement the IActor interface. The rest is mostly code and I don’t want to do a huge code dump on the post. So feel free to browse the source, or better yet, download it into a Flex/Flash builder or Flash CS3/4 and make it your own. I will discuss a few things to look out for before wrapping up the post.

Don’t expose core keys

If you expose the key, which is the unique identifier that identifies a core, anyone can get its facade and manipulate it. This breaks encapsulation. Use the UIDUtil.getUID static method and use the private getter (learned this from an app created by Joel Hooks).

1
2
3
4
5
6
7
8

/**
 * Get unique identifier for this puremvc core
 * Use this key in the call to getInstance( key )
 */
private function get key():String
{
	return UIDUtil.getUID(this);
}

See MoveTheCheese.as and Rat.as to see how this is used in context.

Building multiple applications in a Flex project

If you download the source and build the app, MoveTheCheese.as is the default application. Rat.as need to be built as an application as well because it is loaded in the application mediator. Right click on the project in the Flex Navigator view and choose properties > ActionScript Applications. Now add Rat.as to the runnable applications list.

Advantages of loading Rat.swf

Take a look at the ApplicationMediator class ( ApplicationMediator.as ) constructor. The first rat is instantiated using the new keyword and typed as Rat. The second rat is a loaded Rat.swf file and is typed as DisplayObject. All we know about Rat.swf is that it is a display object that implements the IActor interface. All implementation details are hidden. The loadable rat exemplifies the power of loadable modules. We can easily load a whole bunch of rodents, ants and all kind of pests that conform to theIActor interface. We can distribute development to multiple developers requiring only the swf file in return.

Have a blast with multicore – make sure those snails stick their heads out of their shells.

A while back Brian Lesser, another O’Reilly author and top notch Flash Media Server developer, mentioned that he did not especially care for the Model View Controller (MVC) design pattern. While he cited some references, I never paid much attention to it at the time, especially since Chandima kept writing these brilliant pieces on Pure MVC. Further, I had promised myself that I wouldn’t touch MVC until I had worked my way through all of the design patterns using ActionScript 3.0 and felt comfortable with Flex. So I really am no expert of MVC and have relied on Chandima for that particular compound design.

After weeks of pounding my head on the Prototype pattern, I was thinking of taking a break and sending a torpedo into the Singleton to let off some steam. However, before sticking my neck out (yet again) I thought I’d ask Brian why he didn’t particularly care for the MVC, resulting in a very thoughtful article. (See http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html) Brian asked for Chandima’s and my reaction. Not having spent that much time on the MVC, my reaction was based on the logic of the article which to me made perfect sense. However, this is a case of “What do I know?” The annual OOPSLA conference is coming up this next week and I will be bringing up Brian’s points to big brains that attend OOPSLA–and I hope some more Flex/ActionScript/Flash developers will be there this year! So maybe after next week I’ll have some comments from seriously bright programmers in addition to our seriously bright programmer, Chandima.

So take a look at http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.html and we’d like to get any copies of your comments, thoughts, and wisdom that have you about Brian’s article to post here as well.

Cairngorm or PureMVC?
Recently, Ali Mills and Luke Bayes made a presentation on Flex Application Frameworks. Their choices essentially boiled down to Cairngorm and PureMVC and concluded that PureMVC came out on top. However, I highly recommend that developers watch the whole presentation as many enterprise developers in the audience made comments that challenged the easy differentiation of the two frameworks. Having the backing of a stable organization like Adobe, as is the case with Cairngorm, means a lot for enterprise development. Also, this post on Bill Lane’s blog and several comments implying that PureMVC is much harder to learn than Cairngorm got me thinking if a really simple application would help scaffold the transition to PureMVC.

I’ve implemented the minimalist example from the MVC chapter of our book (available as a free download from Adobe Devnet) using the PureMVC framework. Now this is not a full-fledged application, but a very minimal example meant to explain the inner workings of the PureMVC framework. Before diving in, a brief introduction to some of the important aspects of the framework will help. This was the hard stuff that I had to internalize before starting out. These concepts are more eloquently explained in much greater detail by Cliff Hall in the framework documentation.

“You can’t touch this” – models, views and controllers that is
Although PureMVC is built on the traditional Model-View-Controller meta-pattern, you cannot create or directly manipulate these entities. The Model, View and Controller are already implemented in PureMVC as singletons and are essentially hidden. You do not develop Model, View and Controller classes but implement proxy, mediator, and command classes that broker the communication in your application. The PureMVC Conceptual Diagram shows this visually.

“Collaboration pairs” are better than singles
Cliff introduces the concept of “collaboration pairs”. In the traditional MVC pattern, the Model contains the data and business logic; the View presents the user interface components; and the Controller handles the user input and manipulates the model. However, since the model, view and controller classes are not directly accessible in PureMVC, they form collaboration pairs with other design patterns to provide more abstraction and loose-coupling than the traditional MVC pattern.

The Model – Proxy collaboration pair provides a means to access and manipulate application data. You develop and register a concrete proxy class with the model to provide controlled access to a data object. For example, a proxy can load data files from disk, or provide access to a remote database or web service. The proxy pattern provides an interface to the core application that hides the implementation details of accessing and manipulating data and application state.

The View – Mediator collaboration pair provides the means by which the user interface elements are presented and updated. You develop concrete Mediator classes that register with the View to provide the interface by which the core application communicates with the UI components. A single mediator class can have multiple UI components. For example. a login screen will have one mediator class but can contain username and password fields, and a submit button. The mediator pattern can hide the complex interactions between related UI elements from the core application.

The Command – Controller collaboration pair represents the means by which UI elements can manipulate the model. In a traditional MVC app, the Controller acts as a concrete strategy in a strategy pattern. In this sense, controllers are specific implementations that determine how the application responds to user input. For example, controllers can do validation checks on user input and decide if application data needs to be updated (through a proxy). In PureMVC, the strategy code is encapsulated inside Command Objects. This essentially hides the proxy class and proxy methods that are called to manipulate data objects from the mediator, reducing the coupling between the mediator and the proxy.

Again. the PureMVC Conceptual Diagram does a really nice job of showing the “collaboration pairs.”

Think in Notifications before Events
The mediators, proxies and commands talk to each other using a unique message passing scheme called Notifications. Notifications are essentially triggers that can carry data. Commands are bound to specific notifications. Only mediators listen for notifications. So, a proxy or command can send a notification that will trigger a Mediator to update a UI component. Proxies can send, but do not listen to notifications. A mediator can manipulate application data by sending a notification that will trigger a command to update a data object through a proxy. This shrewd design decision to develop a custom notification scheme has allowd Cliff to port the PureMVC framework to AS2, C#, Java, PHP, and ColdFusion among others.

The Events in Flash and Flex are not discarded, but used at the boundary of the application. Mediators can register and listen for events from UI components such as buttons and fields. Proxies register and listen for events when dealing with data objects such as when loading an XML data file asynchronously.

The Facade is your friend
You must create a concrete Facade class that makes the whole framework easier to use. The Facade provides a single class that unifies all the methods required to make PureMVC work. In addition, instantiating a facade initializes the PureMVC framework by creating the model, view and controller singletons.

These were the four big concepts that I needed to understand before diving into creating a PureMVC application.

The Minimalist Example
The example was developed using Flash CS3 and basically listens for user key presses, stores the last key pressed, and displays the key (MVC_minimalist_v1.zip). The example app was written in PureMVC Release 1.6. The package structure will change in release 2.0 and the import statements will need to be changed accordingly.
Make sure to download and install the PureMVC framework and make it accessible in your classpath first. The package hierarchy as shown in the Flash Project Panel is shown here for reference.

Here is a conceptual diagram that shows the classes and the notification messages. To start the application, call the startup() method in the the Concrete Facade class called ApplicationFacade. The numbers show the sequence of actions that take place.

1. The Concrete Facade class called ApplicationFacade broadcasts a STARTUP Notification.
2. The STARTUP Notification triggers the StartupCommand command object which registers the KeyDataProxy proxy, and StageMediator mediator.
3. StageMediator mediator registers a KEY_DOWN Event handler to the stage to intercept key presses. It also registers to receive KEYUPDATE Notifications.
4. User presses a key generating a KEY_DOWN Event that is intercepted by the key down event handler in the StageMediator.
5. StageMediator broadcasts a KEYDOWN Notification with the character code of the key in the notification body.
6. The KEYDOWN Notification triggers the StoreKeyCommand command object, which accesses the KeyDataProxy proxy and updates the model (data object).
7. The KeyDataProxy proxy stores the data in a data object (just a property in the proxy in this case).
8. The KeyDataProxy proxy broadcasts a KEYUPDATE Notification with the character code of the key in the notification body.
9. The KEYUPDATE Notification handler in StageMediator intercepts the KEYUPDATE Notification and traces the key value.

The StageMediator mediator could have directly updated the model in step 5 through the KeyDataProxy proxy, without going through a command object. However, this introduces a tighter coupling between the Mediator and Proxy that should best be avoided.

The Concrete Facade
The first step is to create a concrete Facade class called ApplicationFacade to declare notification names and bind them to command objects.

The ApplicationFacade class defines the STARTUP, KEYDOWN and KEYUPDATE notification name constants. STARTUP and KEYDOWN are bound to the StartupCommand and StoreKeyCommand comand objects. In contrast, the KEYUPDATE notification is not bound to a command object. It is broadcast by the proxy to mediators informing them that the model has been updated.

The Facade is the entry point into the application and defines the startup() method that broadcasts a STARTUP Notification to the rest of the application. The startup() method has to be called from the document class of your Flash document (see Document Class below). Typically, the argument passed to the startup method should be the stage instance.

ApplicationFacade.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

package {
 
    import org.puremvc.interfaces.IFacade;
    import org.puremvc.patterns.facade.Facade;
    import org.puremvc.patterns.observer.Notification;
    import controller.*;
 
    public class ApplicationFacade extends Facade implements IFacade {
 
        // Notification name constants
        public static const STARTUP:String          = "startup";
        public static const KEYDOWN:String          = "key down";
        public static const KEYUPDATE:String        = "key update";
 
        // Singleton ApplicationFacade Factory Method
        public static function getInstance(): ApplicationFacade {
            if (instance == null) {
                instance = new ApplicationFacade( );
            }
            return instance as ApplicationFacade;
        }
 
        // Broadcast the STARTUP Notification
        public function startup(app:Object):void {
            notifyObservers(new Notification(STARTUP, app));
        }
 
        // Register Commands with the Controller
        override protected function initializeController():void {
            super.initializeController();
            registerCommand(STARTUP, StartupCommand);
            registerCommand(KEYDOWN, StoreKeyCommand);
        }
    }
}

The KEYDOWN notification is sent by the StageMediator Mediator (see below) when a user presses a key. The KEYUPDATE notification is sent by the KeyDataProxy Proxy (see below) to all mediators informing them that the model has changed.

The Commands
There are two command objects StartupCommand and StoreKeyCommand.

StartupCommand.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package controller {
 
    import flash.display.Stage;
    import org.puremvc.interfaces.ICommand;
    import org.puremvc.interfaces.INotification;
    import org.puremvc.patterns.command.SimpleCommand;
    import view.*;
    import model.*;
 
    public class StartupCommand extends SimpleCommand implements ICommand {
        // Register the Proxies and Mediators
        override public function execute(note:INotification):void    {
            // Create and register proxy
            facade.registerProxy(new KeyDataProxy());
            // Create and register StageMediator with the stage instance as an argument
            var stage:Stage = note.getBody() as Stage;
            facade.registerMediator(new StageMediator(stage));
        }
    }
}

When the StartupCommand command object is triggered by the STARTUP notification it first registers the proxy called KeyDataProxy. It then registers the StageMediator Mediator and passes the stage to it. This is an essential practice in Flash applications as the Mediators require access to the stage to add UI components to it. Note that the StartupCommand command object expects the STARTUP notification to contain a reference to the stage in the notification body.

StoreKeyCommand.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package controller {
 
    import flash.display.Stage;
    import org.puremvc.interfaces.ICommand;
    import org.puremvc.interfaces.INotification;
    import org.puremvc.patterns.command.SimpleCommand;
    import model.*;
 
    public class StoreKeyCommand extends SimpleCommand implements ICommand {
 
        override public function execute(note:INotification):void    {
            // Get the KeyDataProxy proxy
            var keyDataProxy:KeyDataProxy = facade.retrieveProxy(KeyDataProxy.NAME) as KeyDataProxy;
            // Set the char code of the key pressed in KeyDataProxy
            var charCode:uint = note.getBody() as uint;
            keyDataProxy.key = charCode;
        }
    }
}

The StoreKeyCommand comand object is triggered by the KEYDOWN notification that is sent by the StageMediator Mediator (see below). The KEYDOWN notification contains the character code of the pressed key in the message body. The command code retrieves the KeyDataProxy using the retrieveProxy() method and stores the character code using a setter method.

The Mediator
The example application just has one Mediator class called StageMediator that mediates interactions with the stage. It registers a Key Down even handler called onKeyDownEvent() with the stage. It also registers to receive KEYUPDATE notifications by overriding the listNotificationInterests() method. It also overrides the handleNotification() method to intercept and act on KEYUPDATE notifications.

StageMediator.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

package view {
 
    import flash.events.KeyboardEvent;
    import flash.display.Stage;
    import org.puremvc.interfaces.IMediator;
    import org.puremvc.interfaces.INotification;
    import org.puremvc.patterns.mediator.Mediator;
 
    // Mediator for interacting with the Stage.
    public class StageMediator extends Mediator implements IMediator {
 
        // Cannonical name of the Mediator
        public static const NAME:String = 'StageMediator';
 
        // Constructor
        public function StageMediator(viewComponent:Stage) {
            // pass the viewComponent to the superclass
            super(viewComponent);
 
            // Listen for events from the view component
            viewComponent.addEventListener(KeyboardEvent.KEY_DOWN, onKeyDownEvent);
        }
 
        // Key down event handler
        private function onKeyDownEvent(event:KeyboardEvent):void {
            sendNotification(ApplicationFacade.KEYDOWN, event.charCode);
        }
 
        // Return list of Nofitication names that Mediator is interested in
        override public function listNotificationInterests():Array {
            return [ApplicationFacade.KEYUPDATE];
        }
 
        // Handle all notifications this Mediator is interested in
        override public function handleNotification(note:INotification):void  {
            switch (note.getName()) {
                case ApplicationFacade.KEYUPDATE:
                    var charCode:uint = note.getBody() as uint;
                    trace(charCode);
                    break;
            }
        }
 
        // Get the Mediator name
        override public function getMediatorName():String {
            return NAME;
        }
    }
}

The StageMediator mediator broadcasts a KEYDOWN Notification when it receives a KEY_DOWN even from the Flash event model. The character code of the key pressed is sent in the body of the Notification. On receipt of a KEYUPDATE Notification, the StageMediator simply traces it to the output panel (to keep things simple). It could have updated a UI element (e.g. Text Field) to show a change.

The Proxy
The minimalist example has one proxy called KeyDataProxy keeps track of the last key pressed by the user. The character code of the key is stored in the lastKeyPressed property in the proxy itself. The proxy could just have easily stored this value in an external data file or remote database if needed.

KeyDataProxy.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package model {
 
    import org.puremvc.interfaces.IProxy;
    import org.puremvc.patterns.proxy.Proxy;
 
    public class KeyDataProxy extends Proxy implements IProxy {
 
        // Cannonical name of the Proxy
        public static const NAME:String = 'KeyDataProxy';
 
        private var lastKeyPressed:uint = undefined;
 
        // Constructor
        public function KeyDataProxy() {
            super(NAME); // pass the cannonical name to the superclass
        }
 
        public function set key(charCode:uint):void {
            if (lastKeyPressed != charCode) {
                lastKeyPressed = charCode;
                // Create and send a KEYUPDATE Notification and pass the charCode as an argument
                sendNotification(ApplicationFacade.KEYUPDATE, charCode);
            }
        }
    }
}

Note that the model stores the new character code only if it is different from the one already stored. It also doesn’t broadcast a KEYUPDATE Notification unless this is the case. This is why we needed two Notification messages, one to broadcast that a key has been pressed (KEYDOWN) and another to inform all interested mediators that the model has been updated with a new character code (KEYUPDATE).

The Document Class
The document class of the Flash document initializes the concrete facade and broadcasts the STARTUP notification.

Main.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package {
 
    import flash.display.MovieClip;
 
    /**
    *   Main Class
    *   @ purpose:      Document class for movie
    */
    public class Main extends MovieClip {
 
        public function Main() {
            // Instantiate the ApplicationFacade
            var facade:ApplicationFacade = ApplicationFacade.getInstance();
 
            // Call the application startup method and pass the stage as the argument
            facade.startup(this.stage);
        }
    }
}

So, there you have it, a minimalist example in PureMVC implemented in the Flash CS3 environment. Make sure you Disable keyboard shortcuts from the Control menu when testing the application. The source can be downloaded below.
MVC_minimalist_v1.zip.

I’ll follow this up with another post extending the minimalist application a little bit (e.g. adding more UI elements and mediators) to demonstrate the value of the design decisions that went into PureMVC. This post is quite long and I’m sure there are some errors – comments and corrections are welcome.