Understanding model-view component architecture
The JavaBeans Component Library contains model-view classes for building
highly maintainable and extensible composite components. This chapter explains
the model-view component architecture.
Basic model-view architecture
JBCL model-view component architecture is a way of composing new components out of basic building blocks by separating component functioning into several objects
within the component. It is an extension of the basic model-view concept,
which separates data handling (storage and data type knowledge) into a
model object and user-interface behavior into a view object.
JBCL composite components extend the basic architecture by further separating out the display of data into an item painter object, thus eliminating
from the view any need for a knowledge of data types.
The advantage of this further separation is the complete elimination
of data-type dependence in the view. A ListControl
can receive its list of items from an array of strings, from a data set
of a database, or from a file directory. The items themselves can be strings,
images, or proprietary data types. As long as the model object implements
the correct model interface (in this case, VectorModel),
and the correct painters are available to display the items on the screen,
the ListControl component functions well.
The VectorModel interface is one of four interfaces defining
the model types in JBCL. They are discussed in Models
in JBCL.
Model-view component functioning
The most basic composite component is
one that instantiates a model, a view, and an item painter of a single
type. The data in this component is homogeneous (of a single data type)
and the component itself does not allow editing of its data items. This
most basic structure is shown below.
Basic model-view-painter component
Using a list as an example, the objects within the composite component
work as shown here:
-
The view receives paint() calls from the Java virtual machine and
calculates what needs painting.
-
The view asks the model for the data item at a specified array index. The
model returns the requested item.
-
The view ask the item painter to paint, passing the item and a Rectangle
in which to paint. The item painter paints the item in the Rectangle.
Model-view components with multiple data types
The simple 3-object (model, view, and item painter) structure works
well as long as the data is always of a single, homogeneous type. Once
the model begins to deliver multiple kinds of data to the view, the
view needs multiple item painters to paint that data. The view cannot choose
among these painters; it knows nothing about the data it passes except
location.
Adding one more element, a view manager, provides the capability of working with multiple data types. A view manager sits between the view and the item painters. For each request, it passes back to the view an item painter (or item editor
object) that handles the given data type.
-
As before, the view receives paint() calls from the Java virtual
machine and calculates what needs painting.
-
The view requests its first data item from the model. The model returns
an Object, in this case a String.
-
The view requests an item painter from the view manager, passing the Object.
The view manager examines the Object, determines its type, and returns
a text item painter.
-
The view asks the item painter to paint, passing the Object and
a Rectangle. The item painter paints the item on the screen.
-
The view requests its next item from the model. This time, the model
returns an Object that is an Image.
-
The view requests an item painter from the view manager, passing the Object.
The view manager examines the Object, determines its type, and returns
an image item painter.
-
The view asks the image item painter to paint, passing the Object
and a Rectangle (the region for painting). The painter paints the
data item on the screen.
Editing items in model-view components
View managers handle item editor objects as well as item painters. Because
an editor must be data-type specific, it is more efficient to move the
selection of editors out of the view and into the view manager.
As in the previous diagram, this list has both text and image items
in it.
-
The user precipitates an event (by double-clicking) that indicates a desire to
edit the first data item.
-
The view requests the data item from the model, passing the item's array
index. The model returns the Object at that location. This Object
is a String.
-
The view requests an item editor from the view manager, passing the Object
and a Rectangle. The view manager examines the Object, determines
its type, and returns the text editor object, which is instantiated (in
the case of text) in the specified Rectangle.
-
The user edits the text while the view listens for keyboard events that
indicate the end of the edit. If the user presses Esc, canceling
the edit, the item editor object is destroyed and the view goes through
the steps to get the original data item repainted. If the user presses
Enter, the view extracts the new value from the item editor before
destroying it.
-
The view passes the changed data item to the model.
-
The model does whatever internal work is necessary to store the new
value. This generates a model event, signaling to the view (and any other
registered listeners) that the data item needs repainting.
-
Receiving the event, the view goes through the steps necessary to repaint
the changed data item.