Newcomers to JFC, including those who learned about the MVC Pattern in another context, are often confounded by the way this pattern is used in JFC components. This is probably because of the common misconception that a user interface is just a view.

Take a text field component, for example. A text field holds its data in a text model (also known as a document). The component obviously has a view that is manifested on the screen. But the component is not passive — It is an active object that can handle user input and other interactions such as text selection and focus transition.

All of these activities are performed by the controller portion of the text field. This controller is separate from any event listeners that may be installed by the user — The controller is built into the collection of classes that provide the core functionality of a text field, and is automatically created when the text field is realized.

A component that has a model, a view, and a controller, may not necessarily represent them through separate objects. Many presentation components combine the view and controller into a single object. Some, such as the label component, do not have a separate model. Others, such as table and text components, may use elaborate collections of objects that are carefully orchestrated behind the scenes. A component itself is simply a well-designed façade that hides all of this complexity.

Presentation components that support the MVC pattern typically have a separate model that maintains the state information for the component. The model notifies dependent views whenever that information changes. Data for such components may be specified in many different ways:

• using markup, directly within the element representing the component,
• using markup, but within a separate element representing the model for the component, or
• using Java™, through a specialized object at run-time.