Documents

Guildhall applets will never be accused of following the Model-View-Controller design pattern. I could never quite wrap my head around that approach, and suffering from that limitation I came up with a similar design pattern. I'll describe that here and someone else can figure out how it relates to MVC.

First off, the greatest similarity to MVC lies in the Model portion of the pattern. Guildhall uses subclasses of ADataType to encapsulate data and to offer methods to manipulate that data. The details of the data are opaque to other classes (well, usually). So in that sense ADataType and Model are very similar constructs.

The View and Controller portions of the pattern are less similar. Certainly ADocument controls a view onto the data, and it generally does that by assembling one or more fields to display that data. Taken as a whole, the document and its fields represents the View portion of the pattern. But they also get involved in the Control portion, and that's where Guildhall's pattern starts to look different.

ADocument subclasses and AField/AFieldList subclasses inherit from the mix-in class MEventHandler. In practice, all events are delivered to an applet's ADocument subclass first. The default functionality of ADocument passes each event to the document's embedded instance of TControls, where TControls subclasses from AFieldList. AFieldList figures out where a given event should go, either to its current target field (for non-positional events) or to some other field it manages based on the positional information (mouse, trackpad, or touch devices).

Once an event reaches the correct handler, processing can take several routes. The most direct route is that a command is created, as a simple text string, and that command is passed to an event handler. The event handler might be the applet's document or it might be another field known to the handler.

A second route would be for the event handler to adjust the data model directly, and make some sort of request to the document and affected fields to update the user's screen.

The third route is for the event handler to instantiate a tracker, a subclass of ATracker that has knowledge of the handler that created it and the data model that the handler is managing. Trackers subsume the document's event handling and can call upon their owner to do some drawing to provide user feedback. Upon completion they may generate commands that effect changes in the data model and which update drawing, although it's rare that a tracker touches the data directly. Does that sound like what a Controller does? Probably. But it clearly isn't a cleanly separate object as most MVC design patterns suggest it should be.

And then in the middle of all this I'll throw out three more constructs. First, menus deliver commands directly to the document that owns them, again in the form of simple text strings. Also, a special field called TBanner can be added to a document's window, and it allows the user to type commands directly to the document's command handler. Finally, the Terminus applet can be used to send commands to any document on the screen if that document is managing an archive visible to Terminus. There really isn't a separate controller in any of those patterns other than the document's command handler.

My conclusion is that Guildhall uses some of the MVC elements, but the Controller element is mostly distributed among several classes.

Abstract Classes

• ADocument

Constructible Classes

• TControls
• TBanner