Chapter 1. (Introduction) Swing Overview. Easy for reading, Click here!

Subpages: 1. Chapter 1. Swing Overview. AWT, Swing 
2. MVC architecture: Model, View, Controller 
3.  Custom models - II, UI delegates and PLAF 

1.3    MVC architecture

MVC is a well known object-oriented user interface design decomposition that dates back to the late 1970s. Components are broken down into three parts: a model, a view, and a controller. Each Swing component is based on a more modern version of this design. Before we discuss how MVC works in Swing, we need to understand how it was originally designed to work.

Figure 1.3 Model-view-controller architecture

<<file figure1-3.gif>>

1.3.1    Model

The model is responsible for maintaining all aspects of the component state. This includes, for example, such values as the pressed/unpressed state of a push button, a text component's character data and information about how it is structured, etc. A model may be responsible for indirect communication with the with the view and the controller. By indirect we mean that the model does not 'know' its view and controller--it does not maintain or retreive references to them. Instead the model will send out notifications or broadcasts (what we know as events). In figure 1.3 this indirect communication is represented by dashed lines.

1.3.2    View

The view determines the visual representation of the component's model. This is a component's "look." For example, the view displays the correct color of a component, whether the component appears raised or lowered (in the case of a button), and the rendering of a desired font. The view is responsible for keeping its on-screen representation updated and may do so upon receiving indirect messages from the model, or direct messages from the controller.

1.3.3    Controller

The controller is responsible for determining whether the component should react to any input events from input devices such as the keyboard or mouse. The controller is the "feel" of the component, and it determines what actions are performed when the component is used. The controller can receive direct messages from the view, and indirect messages from the model.

For example, suppose we have a checked (selected) checkbox in our interface. If the controller determines that the user has performed a mouse click it may send a message to the view. If the view determines that the click occurred on the checkbox it sends a message to the model. The model then updates itself and broadcasts a message, which will be received by the view(s), to tell it that it should update itself based on the new state of the model. In this way, a model is not bound to a specific view or controller, allowing us to have several views and controller's manipulating a single model.

1.3.4    Custom view and conroller

One of the major advantages MVC architecture provides is the ability to customize the "look" and "feel"of a component without modifying the model. Figure 1.4 shows a group of components using two different user interfaces. The important point to make about this figure is that the components shown are actually the same, but they are shown using two different look-and-feel implementations (different views and conrollers -- discussed below).

Figure 1.4 Malachite and Windows look-and-feels of the same components

<<file figure1-4.gif>>

Some Swing components also provide the ability to customize specific parts of a component without affecting the model. More specifically, these components allow us to define custom cell renderers and editors used to display and accept specific data respectively. Figure 1.5 shows the columns of a table containing stock market data rendered with custom icons and colors. We will examine how to take advantage of this functionality in our study of Swing combo boxes, lists, tables, and trees.

Figure 1.5 Custom rendering

<<file figure1-5.gif>>

1.3.5    Custom models

Another major advantage of Swing's MVC architecture is the ability customize and replace a component's data model. For example, we can construct our own text document model that enforces the entry of a date or phone number in a very specific form. We can also associate the same data model with more than one component (as we discussed above in looking at MVC). For instance, two JTextAreas can store their textual content in the same document model, while maintaining two different views of that information.

We will design and implement our own data models for JComboBox, JList, JTree, JTable, and extensively throughout our coverage of text components. Below we've listed some of Swing's model interface definitions along with a brief description of what data their implementations are designed to store, and what components they are used with:

  BoundedRangeModel

Used by: JProgressBar, JScrollBar, JSlider.

Stores: 4 integers: value, extent, min, max.

The value and the extent must be between a specified min and max values. The extent is always <= max and >=value.

  ButtonModel

Used by: All AbstractButton subclasses.

Stores: A boolean representing whether the button is selected (armed) or unselected (disarmed).

  ListModel

Used by: JList.

Stores: A collection of objects.

  ComboBoxModel

Used by: JComboBox.

Stores: A collection of objects and a selected object.

  MutableComboBoxModel

Used by: JComboBox.

Stores: A Vector (or another mutable collection) of objects and a selected object.

  ListSelectionModel

Used by: JList, TableColumnModel.

Stores: One or more indices of selected list or table items. Allows single, single-interval, or multiple-interval selections.

  SingleSelectionModel

Used by: JMenuBar, JPopupMenu, JMenuItem, JTabbedPane.

Stores: The index of the selected element in a collection of objects owned by the implementor.

  ColorSelectionModel

Used by: JColorChooser.

Stores: A Color.

  TableModel

Used by: JTable.

Stores: A two dimensional array of objects.

  TableColumnModel

Used by: JTable.

Stores: A collection of TableColumn objects, a set of listeners for table column model events, width between each column, total width of all columns, a selection model, and a column selection flag.

  TreeModel

Used by: JTree.

Stores: Objects that can be displayed in a tree. Implementations must be able to distinguish between branch and leaf objects, and the objects must be organized hierarchically.

  TreeSelectionModel

Used by: JTree.

Stores: Selected rows. Allows single, contiguous, and discontiguous selection.

  Document

Used by: All text components.

Stores: Content. Normally this is text (character data). More complex implementations support styled text, images, and other forms of content (e.g. embedded components).

Not all Swing components have models. Those that act as containers, such as JApplet, JFrame, JLayeredPane, JDesktopPane, JInternalFrame, etc. do not have models. However, interactive components such as JButton, JTextField, JTable, etc. do have models. In fact some Swing components have more than one model (e.g. JList uses a model to hold selection information, and another model to store its data). The point is that MVC is not hard and fastened rule in Swing. Simple components, or complex components that don't store lots of information (such as JDesktopPane), do not need separate models. The view and controller of each component is, however, almost always separate for each component, as we will see in the next section.

So how does the component itself fit into the MVC picture? The component acts as a mediator between the model(s), the view and the controller. It is neither the M, the V, or the C, although it can take the place of any or all of these parts if we design it to. This will become more clear as we progress through this chapter, and throughout the rest of the book.