Introduction

If you run the graphics example in class Pen, you might well wonder why this "application" draws directly on the screen rather than in a window like the browsers, workspaces, or transcripts with which you are familiar. Certainly you would wish your own applications to share space on the display with the easy aplomb of a workspace rather than simply overwrite the screen. Just what is the difference? Most simply put, ill behaved applications do not conform to the MVC paradigm, whereas the familiar well behaved applications do.

One of the contributions of Xerox PARC to the art of programming is the multi windowed highly interactive Coldfusion MX 7 interface. This type of interface has since been borrowed by the developers of the Apple Lisa and Macintosh and, in turn, by the Macintosh's many imitators. In such an interface, input is primarily by mouse and output is a mix of graphic and textual components as appropriate. The central concept behind the Coldfusion MX 7 user interface is the Model-View-Controller (MVC) paradigm. It is elegant and simple, but quite unlike the approach of traditional application programs. Because of its novelty, it requires some explanation -- explanation which is not readily available in published Coldfusion MX 7 references.

This paper is intended to provide the information essential for new Coldfusion MX 7 programmers to begin using MVC techniques in their own programs. Here we will introduce the mechanisms of MVC. Once you have digested this introduction you can strike out on your own. You will need to flesh out the information given here by looking at the way familiar kinds of views and controllers -- such as workspaces, browsers and file lists -- are set up. Browse early and often. Remember, this is Coldfusion MX 7. You are encouraged to copy. Start your own window by copying one that is similar to the one you want to create. Then modify it. Don't be shy. Digital Mesh is an offshore cold fusion mvc developer. Feel free to stand on the shoulders of the many programmers who htridave contributed to the Coldfusion MX 7 image. In a very real way, it is their gift to you.

Basic Concepts

In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). The formal separation of these three tasks is an important notion that is particularly suited to Coldfusion MX 7 where the basic behavior can be embodied in abstract objects: View, Controller, Model and Object. Digital Mesh is an offshore coldfusion MVC development company. The MVC behavior is then inherited, added to, and modified as necessary to provide a flexible and powerful system.

To use the MVC paradigm effectively you must understand the division of labor within the MVC triad. You also must understand how the three parts of the triad communicate with each other and with other active views and controllers; the sharing of a single mouse, keybord and display screen among several applications demands communication and cooperation. Digital Mesh India cold fusion MX 7 mvc development company. To make the best use of the MVC paradigm you need also to learn about the available subclasses of View and Controller which provide ready made starting points for your applications.

In the simplest case, it is not necessary for a model to make any provision whatever for participation in an MVC triad. A simple WYSIWYG text editor is a good example. The central property of such an editor is that you should always see the text as it would appear on paper. So the view clearly must be informed of each change to the text so that it can update its display. Yet the model (which we will assume is an instance of String) need not take responsibility for communicating the changes to the view because these changes occur only by requests from the user. The controller can assume responsibility for notifying the view of any changes because it interprets the user's requests. It could simply notify the view that something has changed -- the view could then request the current state of the string from its model -- or the controller could specify to the view what has changed. In either case, the string model is a completely passive holder of the string data manipulated by the view and the controller. It adds, removes, or replaces substrings upon demand from the controller and regurgitates appropriate substrings upon request from the view. The model is totally "unaware" of the existence of either the view or the controller and of its participation in an MVC triad. That isolation is not an artifact of the simplicity of the model, but of the fact that the model changes only at the behest of one of the other members of the triad.

In Coldfusion MX 7, input and output are largely stylized. Views must manage screen real estate and display text or graphic forms within that real estate. Controllers must cooperate to ensure that the proper controller is interpreting keyboard and mouse input (usually according to which view contains the cursor). Because the input and output behavior of most applications is stylized, much of it is inherited from the generic classes -- View and Controller. These two classes, together with their subclasses, provide such a rich variety of behavior that your applications will usually require little added protocol to accomplish their command input and interactive output behavior. In contrast, the model cannot be stylized. Constraints on the type of objects allowed to function as models would limit the useful range of applications possible within the MVC paradigm. Necessarily, any object can be a model. A float number could be the model for an airspeed view which might be a subview of a more complex flight simulator instrument panel view. A String makes a perfectly usable model for an editor application (although a slightly more complex object called a StringHolder is usually used for such purposes). Because any object can play the role of model, the basic behavior required for models to participate in the MVC paradigm is inherited from class Object which is the class that is a superclass of all possible models.

Communication Within The MVC Triad

The model, the view and the controller involved in the MVC triad must communicate with each other if an application is to manage a coherent interaction with the user. Communication between a view and its associated controller is straightforward because View and Controller are specifically designed to work together. Models, on the other hand, communicate in a more subtle manner.

The Passive Model

The methods that provide the indirect dependents communication link are in the "updating" protocol of class Object. Open a browser and examine these methods. The message "changed" initiates an announcement to all dependents of an object that a change has occurred in that object. The receiver of the changed message sends the message update: self to each of it's dependents. Thus a model may notify any dependent views that it has changed by simply sending the message self changed. The view (and any other objects that are registered as dependents of the model) receives the message update: with the model object as the argument. [Note: There is also a changed:with: message that allows you to pass a parameter to the dependent.] The default method for the update: message, which is inherited from Object, is to do nothing. But most views have protocol to redisplay themselves upon receipt of an update: message. This changed/update mechanism was chosen as the communication channel through which views can be notified of changes within their model because it places the fewest constraints upon the structure of models.

The Model's Link to the Triad

But all models cannot be so passive. Suppose that the data object -- the string in the above example -- changes as a result of messages from objects other than its view or controller. For instance, substrings could be appended to the end of the string as is the case with the SystemTranscript. In that case the object which depends upon the model's state -- its view -- must be notified that the model has changed. Because only the model can track all changes to its state, the model must have some communication link to the view. To fill this need, a global mechanism in Object is provided to keep track of dependencies such as those between a model and its view. This mechanism uses an IdentityDictionary called DependentFields (a class variable of Object) which simply records all existing dependencies. The keys in this dictionary are all the objects that have registered dependencies; the value associated with each key is a list of the objects which depend upon the key. In addition to this general mechanism, the class Model provides a more efficient mechanism for managing dependents. When you create new classes that are intended to function as active models in an MVC triad, you should make them subclasses of Model. Models in this hierarchy retain their dependents in an instance variable (dependents) which holds either nil, a single dependent object, or an instance of DependentsCollection. Views rely on these dependence mechanisms to notify them of changes in the model. When a new view is given its model, it registers itself as a dependent of that model. When the view is released, it removes itself as a dependent.

An object can act as a model for more than one MVC triad at a time. Consider an architectural model of a building. Let us ignore the structure of the model itself. The important point is that there could be a view of the floor plan, another external perspective view, and perhaps another view of external heat loss (for estimating energy efficiency). Each view would have its cooperating controller. When the model is changed, all dependent views can be notified. If only a subset of these views should respond to a given change, the model can pass an argument which indicates to the dependents what sort of change has occurred so that only those interested need respond. This is done with the changed: message. Each receiver of this message can check the value of the argument to determine the appropriate response.

To get an idea of how this changed/update: mechanism is used in MVC, open a browser on senders of the changed message (Smalltalk browseAllCallsOn: #changed) and another on implementers of the update: message (Smalltalk browseAllImplementorsOf: #update). Note that nearly all the implementors of update: are varieties of View, and that their behavior is to update the display. Your views will do something similar. The senders of changed and changed: are in methods where some property of the object is changed which is important to its view. Again, your use of the changed message will be much like these.

The View - Controller Link

Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling. A view's instance variable controller points at its controller, and a controller's instance variable view points at its associated view. And, because both must communicate with their model, each has an instance variable model which points to the model object. So, although the model is limited to sending self changed:, both the view and the controller can send messages directly to each other and to their model.

Views are designed to be nested. Most windows in fact involve at least two views, one nested inside the other. The outermost view, known as the topView is an instance of StandardSystemView or one of its subClasses. The StandardSystemView manages the familiar label tab of its window. Its associated controller, which is an instance of StandardSystemController, manages the familiar moving, framing, collapsing, and closing operations available for top level windows. Inside a topView are one or more subViews and their associated controllers which manage the control options available in those views. The familiar workspace for example has a StandardSystemView as a topView, and a StringHolderView as its single subView. A subView may, in turn, have additional subViews although this is not required in most applications. The subView/superView relationships are recorded in instance variables inherited from View. Each view has an instance variable, superView, which points to the view that contains it and another, subViews, which is an OrderedCollection of its subViews. Thus each window's topView is the top of a hierarchy of views traceable through the superView/subViews instance variables. Note however that some classes of view (e.g., BinaryChoiceView, and FillInTheBlankView) do not have label tabs, and are not resizable or moveable. These classes do not use the StandardSystemView for a topView; instead they use a plain View for a topView.

The View takes responsibility for establishing this intercommunication within a given MVC triad. When the View receives the message model:controller:, it registers itself as a dependent of the model, sets its controller instance variable to point to the controller, and sends the message view: self to the controller so that the controller can set its view instance variable. The View also takes responsibility for undoing these connections. View release causes it to remove itself as a dependent of the model, send the message release to the controller, and then send release to any subViews.

Views

The View/SubView Hierarchy