The Bean Builder Architecture

This document describes the basic architecture of the Bean Builder.

Model

The root object is the top level object in the designer. Most likely, this Object is an AWT/Swing container like a JFrame or a JPanel. The Bean Builder also supports general top level Containers which may be inferred with Reflection based on the existence of methods: add(Object), remove(Object) and Object[] getChildren().

The root container is the parent container for all the visual objects that are added to the design. In some curcumstances the root object and the root container can refer to the same object. For example, if the root object is a JPanel then the root container is same JPanel. If the root container is a JFrame, then the root container is the JPanel returned from JFrame.getContentPane().

ObjectHolder: The design repository for the builder is a singleton instance. All manipulation on the root object is done through the ObjectHolder repository. This class also manages the listeners interested in the changing state of the objects contained within the root object.

The ObjectHolder singleton fires PropertyChangeEvents when the state of the model changes. All classes which are interested in reacting to these changes should register itself as a PropertyChangeListener.

The ObjectHolder acts as a proxy event source for ComponentListeners and ContainerListeners on components within the root container. Objects which are interested in Component or Container events should register themselves as listeners through this proxy mechanism. This is necessary to avoid adding design time listeners on the components themselves so that the Long Term Persistence doesn't store those listeners. A better solution would be to have mark the designer listeners with a tagging interface and use the new get<Foo>Listeners() API to remove the designer specific listeners for Serialization and then restore them.

The Bean Builder designer support non-visual beans - which are beans that don't inherit from java.awt.Component. The ObjectHolder manages the relationship between non-visual beans and the visual proxy that represents that bean within the designer.

Designer

One of the challenges of creating a programming environment that edits a "live" application is the separation of design time gestures from the runtime behavior of the application. When the tool is in design mode, visual cues appear that allow for the instantiation, selection and manipulation of objects. This is achieved by swapping the original glass pane of the JFrame with a glass pane which can interpret mouse gestures into designer events. All the handles which indicate the selected object, or targets for other UI gestures are located on this design time glass pane.

GlassPane: The base class of the editing panes which handles basic object selection and instantiation. This class contains an instance to an InstantiationHandler - which interprets mouse gestures and is responsible for creating new instances of Objects from the Palette. The GlassPane also contains the basic architecture for Handle and Arc management. Currently there are two subclasses of GlassPane.

EventPane: A panel for wiring interactions between JavaBeans and seting objects as properties of other Objects. The EventLinkHandler interprets mouse gestures between the components and will invoke a Wizard dialog in the EventPane if the gesture represents the creation of an object relationship.

LayoutPane: A panel for the visual manipulation and joining of edges between Components with the SpringLayout layout manager. The EdgeLinkHandler is responsible for interpreting mouse events in this editor to constraints which link components.

Handles The Handle class hierarchy is respresents a set of objects which are placed around a component that allow for the manipulation of that component. A handle has an identity and knows which object it represents. EventHandles and LayoutHandles are on all the components within the designer but selection Handles are only on the selected component.

Arcs Arcs represent relationships between objects. These relationships are linked between two handles and may be directional. In the Bean Builder an arc may represent a property association, and event relationship or a constraint binding between two components.

Controller

ActionManager: All the actions of the Bean Builder are instances of a javax.swing.Action and are registered with the ActionManager in the com.sun.java.swing.action package. The actions themselves are instances of a DelegateAction which delegates the actionPerformed method to a registered ActionListener. An application should subclass the ActionManager to construct and add specific actions.

CommonMenuBar and CommonToolBar: These two abstract classes in the com.sun.java.swing.ui package are helper classes that use the ActionManager architecture. Application specific subclasses should override the abstract methods to build the menus or toolbars with the actions retrieved from the ActionManager subclass.

The ActionManager architecture including the CommonToolBar and CommonMenuBar support ItemStateChange (or "toggle" type) actions which are implemented by JToggleButton, JCheckBoxMenuItem and JRadioButtonMenuItem. Any action which changes its selection state (like for toggle buttons or check box menu items) should subclass StateChangeAction.

Palette: All classes in the palette package are responsible for the management and instantiation of items on the component palette. The palette items and tabs are externally configurable and are represented in a well formed document schema. By default the Bean Builder will load the first instance of palette.xml that it finds in it's classpath. You may specify any palette on startup with the -p option or you may load any palette through the main menu.

The Bean Builder, is a product of Sun MicrosystemsTM, Inc. For answers to common questions and further contact information please see the java.sun.com Help Pages.

Copyright © 1997-2002 Sun Microsystems, Inc. All Rights Reserved. Terms of Use. Privacy Policy.