Previous Next

Bean Works Programming Model

Model-View-Controller Component Design

When you use the Bean Works model-view-controller programming model, you build a component from a set of objects that each controls a different aspect of the component's functionality: data management, data "rendering" or interpretation, and user interface (UI) management. These objects work together to provide the functionality the end user sees:

CAF Component Model

Bean Works provides defaults for much of the generic functionality for your Java program, so you can choose how much of the model-view-controller paradigm you want to implement. You can also easily prototype components by using the framework defaults while you focus on developing the core features unique to your component.

At a minimum, you always need to implement a view that renders data somehow -- for example, displaying it on the screen; the default Bean Works controller handles launching (of the application, applet, or bean) and provides windowing, basic menus, and a standard toolbar. For example, you could create a simple "Hello World" application just by creating a view that draws a text string to the screen and using the default controller:

Default controller features

This program represents one of the simplest applications of the Bean Works framework. The application doesn't require a model, because the component's "data," the string Hello World, is coded into the view's paint routine, and doesn't need to be manipulated by the user or saved as part of a unique document created by the component. You need to create a model for your component to let the user enter and manipulate data and save any changes made (essentially, saving documents generated by the component). Likewise, you can create a customized controller to provide additional UI features, for example, menus, toolbars, and specialized event handling.

The following sections describe each of the parts of a component in more detail, describing how you can extend them to add more features to your components. See Bean Works Architecture for specific information on the underlying classes.

Creating the data model

A model provides the fundamental data management for a component. The model:

When you develop a component, you create a model that provides functionality specific to the types of data your component works with. This means you need to:

Note that, in most cases, you want the access to the data in your model to be selection-based, meaning that the user can select some subset of the data in a model to manipulate. When a user issues a command against the selected data, the command object accesses the data through the selection object rather than calling methods on the model directly:

Selection Interface

This layered approach supports the serially undoable command mechanism, and, by maintaining the separation between the data and the interfaces that allow clients to manipulate the data, makes your components more extensible and ensures the integrity of your data. Selections and commands are described in more detail in Selecting and Manipulating Data. You can also create programs that use other mechanisms to modify data.

As noted earlier, not all components require a data model. If your component does not let the user directly manipulate and save data, you probably don't need to create a model. Components of this type may be either very simple components, such as a game that always begins with the same state and does not need to be persisted, or a component such as a simple stock ticker which simply provides a mechanism for accessing and presenting data that is maintained by some other source.

Presenting data

You implement the ability to present data by creating a view for your component. Most of the time your views will draw data to the screen. A view can, however, render the data in other ways, such as sending data to a log file or creating an audio track. You can also create multiple views for a single model that present the data in different ways and that can be used to build different types of components.

To ensure that the presentation stays synchronized with updates to data, views are typically listeners for changes to both the model and the model selection. The view gets notified when the data in the model is modified, and redisplays the data accordingly. Likewise the view gets notified when the user selects or deselects data, and can display the correct selection indicators, for example, highlighting selected text or drawing an outline around selected graphic objects. Your view can redraw itself entirely or redraw only modified areas, based on the complexity of the view and the performance needs.

The view also often acts as an event handler, allowing the user to directly manipulate onscreen data using the mouse or keyboard. To add event handling to your view, use the event delegation model implemented by the Java AWT package. This package provides listener interfaces you can implement for different types of events you might be interested in, such as mouse motion or keystrokes. You can use these methods to implement mechanisms allowing the user to select and manipulate data, for example, selecting an object by clicking on it or moving an object by dragging it or using arrow keys.

Tying it together: the component controller

The controller acts as the glue for the component, and has the responsibility for:

The controller is in essence the primary bean for a Bean Works component. It owns any other beans that make up the component, such as the model, view, and GUI elements, and delegates events to them as necessary.

Initializing the component

The controller handles most of the initialization for the program. It uses a resource loader object to identify variable information such as:

Separating this information from the controller itself makes your components more flexible and reusable, because you can create variations on your component by editing the resource loader data and relaunching the component. You could, for example, create a different type of applet or use a different view object to display the data in the model. The resources are defined by strings for easy modification:

Resource loading

Any of the string resources in the resource loader can be edited at any time, allowing you or a translator to easily localize the program interface. You can create resource loader objects for different languages, and the controller will read in whichever resources are present at runtime.

If you use the Bean Wizard to create your component, the resource loader class is built for you automatically. Currently, however, you must add the menu resources manually. Menu resources listed in the resource loader class are loaded by the GUIHandler when the UI for the component is constructed.

You can also specify a custom splash screen to be displayed as a component is being launched.

Routing events

The controller's GUIHandler also acts as the high-level event router for the component. Some events are handled by the view—for example, mouse interactions that allow the user to directly manipulate data displayed by the view. Events that involve interaction with the GUI, such as pressing a menu item or tool button, are handled by the GUIHandler via the command processor. This mechanism upholds the partitioning of the model-view-controller paradigm, maintaining the separation between the display of data (handled by the view) and the storage of data (handled by the model):

Event routing

See Enabling Undoable Commands for information on the framework's command processing mechanism.

The Bean Wizard lets you specify how the controller should route events. You can:

Event handling for the standard controller features, such as default menus and windowing, is implemented automatically.


Previous Next

Copyright © Taligent, Inc. 1996 - 1997.
Copyright
© IBM Corporation 1996 - 1997.
All Rights Reserved.