and feel that acts like a specific platform. For example, if you know that an application will
be running only in a Windows environment, it is possible to specify the Windows look and
feel. It is also possible to design a custom look and feel. Finally, the look and feel can be
changed dynamically at run time.
Java SE 6 provides look-and-feels, such as metal and Motif, that are available to all Swing
users. The metal look and feel is also called the Java look and feel. It is platform-independent and
available in all Java execution environments. It is also the default look and feel. Windows
environments also have access to the Windows and Windows Classic look and feel. This
topic uses the default Java look and feel (metal) because it is platform independent.
The MVC Connection
In general, a visual component is a composite of three distinct aspects:
· The way that the component looks when rendered on the screen
· The way that the component reacts to the user
· The state information associated with the component
No matter what architecture is used to implement a component, it must implicitly contain
these three parts. Over the years, one component architecture has proven itself to be
exceptionally effective: Model-View-Controller, or MVC for short.
The MVC architecture is successful because each piece of the design corresponds to an
aspect of a component. In MVC terminology, the model corresponds to the state information
associated with the component. For example, in the case of a check box, the model contains
a field that indicates if the box is checked or unchecked. The view determines how the
component is displayed on the screen, including any aspects of the view that are affected
by the current state of the model. The controller determines how the component reacts to the
user. For example, when the user clicks a check box, the controller reacts by changing the
model to reflect the user 's choice (checked or unchecked). This then results in the view
being updated. By separating a component into a model, a view, and a controller, the
specific implementation of each can be changed without affecting the other two. For instance,
different view implementations can render the same component in different ways without
affecting the model or the controller.
Although the MVC architecture and the principles behind it are conceptually sound,
the high level of separation between the view and the controller is not beneficial for Swing
components. Instead, Swing uses a modified version of MVC that combines the view and
the controller into a single logical entity called the UI delegate. For this reason, Swing's
approach is called either the Model-Delegate architecture or the Separable Model architecture.
Therefore, although Swing's component architecture is based on MVC, it does not use a
classical implementation of it.
Swing's pluggable look and feel is made possible by its Model-Delegate architecture.
Because the view (look) and controller (feel) are separate from the model, the look and feel
can be changed without affecting how the component is used within a program.
Conversely, it is possible to customize the model without affecting the way that the
component appears on the screen or responds to user input.
To support the Model-Delegate architecture, most Swing components contain two objects.
The first represents the model. The second represents the UI delegate. Models are defined
Search WWH :