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.
I recently commented on a provocative post by Jovan Sranojlovic called “Do Not Use Design Patterns Upfront” He made some thoughtful observations on why design patterns are important to software engineering and how they can a abused in that context as well. However, I disagreed with his basic thesis that design pattern should only be applied in a code refactoring context and not before. Based on his argument, thinking in design patterns upfront, based on the intent and purpose of code in not good, and even harmful. I tweeted my disagreement with a link to JUnit A Cook’s Tour, an example of, what I thought was, thinking in design patterns at the application design stage. The resulting tweet stream follows:
“Do Not Use Design Patterns Upfront” http://tr.im/uI3a – I don’t agree. Beck & Gamma did just that with JUnit http://tr.im/uI3z #asdp
1:09 AM Jul 30th by @chandimac
@chandimac no we didn’t. we explained junit with patterns, but we started with one tiny test and grew the whole thing from there.
6:33 AM Jul 30th by @kentbeck in reply to @chandimac
@kentbeck TX for the clarification. Do you recommend “thinking in patterns” early or should they be added at a later refactoring stage?
6:30 AM Jul 31st by @chandimac in reply to @kentbeck
@chandimac i prefer to put patterns in place just before they become useful. if i can’t see how to do that, then soon after.
6:51 AM Jul 31st by @kentbeck in reply to @chandimac
JUnit A Cook’s Tour explains the design of a system by starting with nothing and applying patterns, one after another, until you have the architecture of the system. As Kent pointed out, the article was written that way, and I had incorrectly assumed that JUnit was developed that way as well.
Design Pattern wisdom in 140 characters
I put patterns in place just before they become useful. If I can’t see how to do that, then soon after.
– Kent Beck
I was quite intrigued by Kent’s reply to my follow up question. It got me thinking about a bunch of issues. What does it mean for a design pattern to be “useful?” How much before is “just before?” What does it mean to “put patterns in place?”
I was so intrigued that I re-read a bunch of stuff on refactoring and design patterns by Beck, Gamma, Kerievsky and Alexander. I try my best to answer some of the questions raised in the remainder of this post – or more appropriately, reconcile some of my cognitive dissonance. Read more…
Although it may be a small conceptual leap for someone who has experience with the single-core version of PureMVC to visualize how multicore works, it can be a little daunting for a novice. This post describes the design and development of a simple game concept to exemplify the utility of PureMVC multicore. This is a pure AS3 app that doesn’t use the Flex framework. You can download the source and build the app in Flex/Flash Builder (as an AS3 project) or Flash CS3/4.
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.
Read more…
A couple of readers suggested that a full-fledged example might be a good follow-up to my previous post introducing the iterator pattern. This is a good suggestion as there are few meaningful examples of the iterator pattern that demonstrate its intent and usefulness. This is probably due to the iterator pattern being a built-in construct in most programming languages. However, built-in iterators are designed to traverse native collections such as Arrays and Dictionaries. To traverse a custom data structure, we need to develop an iterator from the ground-up. In this example, we will develop a webpage scraper, like Googlebot, that recursively harvests information from web pages.
Why is an iterator pattern a good candidate for use in developing a webpage scraper? As described in my previous post, the iterator pattern provides a uniform way to traverse and access elements in a collection. A web page is a collection of elements. To harvest the elements ( tags ) we need to traverse and access the elements in the collection (HTML). The iterator pattern light bulb should go off at this point.
Having a uniform interface to access different elements in the web page is very desirable. Why? because there are multiple ways to traverse and access different elements. We can develop several concrete iterators to access different tags. In this example, we will develop two concrete iterators: one to access hyperlinks and the other to access images.
The example will be developed in two parts. My initial novice attempt will be described first ( I’ll call this version 1 ). I initially treated a web page as an XML document, so that E4X could be used to traverse and identify elements. However, this introduced a major limitation in that only well-formed web pages could be scraped. This didn’t mean that the web pages had to be declared as XHTML Strict per se, but each page had to be structured according to the rules defined in Section 2.1 of the XML 1.0 Recommendation. So, any malformed web pages with missing closing tags, or funky characters would fail the test. In my second attempt (version 2), I treated web pages as text documents and used regular expressions to identify elements. This introduced another more serious limitation in that my knowledge of regular expression pattern matching was minimal. So, version 2 was more of an adventure in slaying the regular expression dragon than anything else. However, the utility of the iterator was amply demonstrated as I could extend the scraper app to meet the new reqruiement without changing any existing code – the ultimate test in reusability. Here is the initial class diagram.
Webpage scraper – version 1
Class diagram of version 1
Read more…
We tend to think of the iterator pattern as simply a mechanism to access a collection of items in some sort of order. However, the motivation for the iterator pattern goes quite a bit beyond this everyday requirement. It is specifically designed to hide how you decide to structure the collection, but still provide a uniform interface to traverse and access its elements. We will look at a couple of examples where we change how the collection is implemented but keep the client oblivious to the change.
Let’s take a look at the class diagram to determine the relationships between the classes in the iterator pattern.
Read more…
Several months ago, I was looking for a framework that would streamline AS3 application development. Cairngorm and PureMVC were the most mature frameworks out there and I remember being particularly impressed with PureMVC mainly due to the solid documentation that came with it. Cairngorm may be robust, but I just couldn’t get my head wrapped around it by glancing at the docs and examples. In contrast, PureMVC came with a Conceptual Diagram that explained the framework using the design patterns that I was familiar with. Cairngorm does have similar diagrams that explain its microarchitecture, but it exemplifies my initial thoughts — I just couldn’t get a quick, big picture understanding of it easily. Not only has Cliff Hall done a masterful job on the PureMVC framework, but the effort he’s put into the documentation really underscores the importance of documentation and diagrams on dissemination and adoption.
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.
Read more…
Two chapters from the ActionScript 3.0 Design Patterns book are available as a free download from devnet. Each chapter contains multiple examples. The factory method pattern chapter includes a print shop application, a sprite factory, and a shooter game that uses the factory method pattern to create different types of projectiles. The MVC chapter includes a weather map application and a car chase app.
Video of Lee Brimelow’s session from AIR Camp Denver. Lee does a fantastic job of placing Adobe Air in the crowded field of Flash, Flex, Microsoft’s Silverlight and desktop apps. He demos several apps showing the capabilities of AIR apps including custom chrome and most importantly, the impressive speed of AIR apps running on the desktop, including several that use the Papervision3D library. He also shows how to create AIR apps using the excellent AIR Panel developed by the folks at gskinner.com (Note: Adobe now has an update for creating AIR apps from Flash CS3).
AIR opens a whole new discussion about best practices on developing desktop apps integrating ActionScript, HTML, Javascript and PDF and how to integrate design patterns that work seamlessly across multiple development frameworks.
This is part two of a two part series on developing the structure of a book using the composite pattern. In part 1, we treated pages as primitive component objects. However, pages can be further decomposed to contain text blocks and images. This example illustrates the utility of the composite pattern by demonstrating how easy it is to extend an application that implements the composite pattern by adding new composite and component classes that extend existing ones.
Read more…
Bill Sanders
Recent Comments