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:

Block diagram of internal workings of a simple model-view-painter component.

  1. The view receives paint() calls from the Java virtual machine and calculates what needs painting.
  2. The view asks the model for the data item at a specified array index. The model returns the requested item.
  3. 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.

Block diagram of a model-view component with heterogeneous data items.

  1. As before, the view receives paint() calls from the Java virtual machine and calculates what needs painting.
  2. The view requests its first data item from the model. The model returns an Object, in this case a String.
  3. 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.
  4. The view asks the item painter to paint, passing the Object and a Rectangle. The item painter paints the item on the screen.
  5. The view requests its next item from the model. This time, the model returns an Object that is an Image.
  6. The view requests an item painter from the view manager, passing the Object. In this implementation, the view manager examines the Object, determines its type, and returns an image item painter. In your own implementation of the ViewManger interface, you could have the view manager behave differently.
  7. 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.

Block diagram of a model-view component's item editing process.

As in the previous diagram, this list has both text and image items in it:

  1. The user precipitates an event (by double-clicking) that indicates a desire to edit the first data item.
  2. 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.
  3. The view requests an item editor from the view manager, passing the Object and a Rectangle. In this implementation, 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. In your implementation of ViewManager, you could have it behave differently.
  4. 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.
  5. The view passes the changed data item to the model.
  6. 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.
  7. Receiving the event, the view goes through the steps necessary to repaint the changed data item.
For more information about how a model-view component such as ListControl works, read Writing a composite component.