Views and Files

The classes Displayer, View, and File need a little tweaking: Displayer-View does not quite deal with nested views, and File does not know how to handle Models. Here is my analysis of what is needed.

Here is the object model of these classes:



Displayer-View

The problem with displayer-view is that nested views are not handled well. An example of this problem is the presence of bogus entries in the Window menu when IDoc windows are opened. Additionally, every subview has bindings that allow associated windows such as search dialogs and revision control to be opened on the subview, whereas we only want this to happen with rootviews.

Cause

Views do not know that they can either be a rootview of the tree of views or a subview. Subviews are currently given access to the containing Displayer and add themselves to the Window menu. Subviews add bindings to themselves for creating associated windows.

Solution

The solution requires making clear the distinction between rootviews and subviews. The constructor of View sets a flag, say isRoot, and modifies the binding tags of each subview to include the names of its parents.

In attachDisplayer, the view only gives itself a reference to its Displayer if it is an immediate child. The attachView method takes additional arguments that allow a subview to share StatusBars with the root object.


File-Resource-Model

The File class is designed with the assumption that each instance usually references a single Resource (which is usually a disk file). When a second File widget is opened on a writable Resource, File warns the user that there are two Views on the writable Resource, but does not provide a way for the two Views to communicate and synchronize.

Cause

The -file option of File does not provide a "hook" that subclasses can override in order to handle the case in which multiple views are open on the one Resource.

Solution

The protected method _alreadyOpen is called if the given file is already open. By default, this hook method gives the user a warning -- subclasses can override it to create or access shared Models.


JohnR, 28 Oct 97