Smalltalk and Object Orientation: an Introduction - Free

26.4 Views and subviews
In the example in the previous section, it is unlikely that the button would actually have been handled by
the window controller or that the window view would have determined how it was displayed. Rather the
button would have had its own ButtonView and associated ButtonController (indeed Figure 26.4 and
Figure 26.5 suggest this). The ButtonView would have been a subview of the main window and would
have been responsible for displaying the button and checking whether the mouse was over the button.
In fact views are designed to be nested. Most windows actually involve at least two views, one
nested inside the other. The outermost view, known as the top component, manages the familiar
window features (for example, the window menu bar etc.). It has an associated controller which
manages the familiar moving, framing, collapsing and closing operations available from windowing
environments.
Inside the top component are one or more subviews, known as components, and their controllers
(remember almost all views have an associated controller) which manage specific elements of the view
(e.g. buttons, scroll bars, selection boxes etc.). The subview (component) refers to the view it is an
element of, as its container. Thus a subview is held within a c ontainer and a container possesses
components (which are its subviews).
A component may, in turn, have additional components (although this is often not required). The
container/component relationships are recorded in instance variables within the views. Each component
has a link to its container and a container possesses an ordered collection of components. Thus each
window’s top component is the top of a hierarchy of components.
Typically, this means that when creating a window you first instantiate the top most view and then
create and place subviews within the top level view. Figure 26.9 illustrates exactly this for a very simple
window. This is a working example which you can type into a Workspace and evaluate.
The actual source code can be broken down into three sections. The first section creates a new
ScheduledWindow. Scheduled windows represent the top connection to the host window system 13 .
They are always the top of the view hierarchy (that is they are always t he top component). Scheduled
windows can have a label, a minimum and maximum size, can possess a single component (which can
be made up of multiple views), possess a StandardSystemController (a controller specifically
designed to work with scheduled window s) and of course a model. Having created the scheduled
window, the code sets its controller, gives the window a label and specifies its minimum size.
Figure 26.9: Creating a simple window
The second part of the code creates a composite part. A composite part is essentially a view which is
made up of one or more subviews. That is, it is a collection of subviews and appropriate behaviour for
handling these subviews 14 . In the example in Figure 26.9, two components are added to the
compositePart. One is a very simple view which is a composed text. Composed texts allow strings to be
displayed as a view. Note that it is the compositePart which determines where the ‘Hello’ will be
13
“Scheduled” really relates to the fact that all ScheduledWindows are held by a control manager which determines
(schedules) which of them is active at any one moment in time. Note only one window can be active for user input at any
particular moment.
14
There is of course more to it than that, involving Wrappers and VisualComponents, however as these are essentially
modifications of the basic MVC we shall leave an investigation of this issue to the reader.
220