ActionScript 3.0 Design Patterns

This is not an introduction to the MVC pattern, but a look into its implementation in Smalltalk-80 to understand the original intent and function of the Model, View, and Controller triad. Starting with the “classic” MVC helped me understand the evolution of the presentation patterns that came after it. We will look at how a simple MVC app works in Smalltalk-80 and examine how it can be implemented in ActionScript. I am not a Smalltalk programmer and my first task was to find some good resources.

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. Read more…

We got a request for a post on the Model-View-Presenter (MVP) pattern sometime back. As always, I did some digging and realized that there were very few examples of MVP that described its implementation well enough for someone to  understand the subtleties of the pattern.

Subtle differences

Subtleties are the key issue with implementing presentation patterns.  When I say subtleties, I mean much more that the how, of the implementation, but the why as well. Why would you want to implement an MVP architecture as opposed to an MVC? What are the potential advantages and disadvantages? I ended up comparing and contrasting GUI architectures such as MVP, MVC, Presentation Model, Supervising Controller and Passive View. When I found an example of an MVP, I found myself coming back to Martin Fowler’s work on Enterprise Application Architectures to iron out my doubts on the implementation. Fowler has not only done an excellent job of describing the differences between presentation patterns, but ties in the history and evolution of GUIs as well.

Separation of concerns

Separated presentation is a key theme in all GUI architectures. Much of the discussion on GUIs concentrate on separating the presentation layer elements, such as presentation logic and user-interface widgets, from the rest of the application. This separation is useful in that dependencies between the presentation layer and the rest of the application can be managed, allowing more effective development and testing.  This is essential in Flash development because we deal with very rich GUIs that contain many complex UI widgets. Architecting the application to allow distributed modular development of the presentation layer can go a long way in streamlining the development workflow.

Walk-the-walk

This is the introductory post on a series of upcoming posts on presentation patterns where I take a mindful walk on the path carved out by Martin Fowler in his chapter on GUI Architectures. Mindful in the sense that I’m bringing a Flash and ActionScript mindset to the journey. This path has been traveled before, by Paul Williams. For contrast, I’ll be using the weather maps sample application from Chapter 12 in our book to provide a fresh set of examples on the following presentation patterns.

• The Classic Model-View-Controller ( MVC )
• Autonomous View
• Model-View-Presenter (MVP)
• Passive-View