next up previous NU-CCS-99-04.ps [ Readme | Copyright | Tutorial | Download | Feedback ]


Next: Manipulation and Representation of Up: Understanding the Assembly-Design Space Previous: Visuality, Symbolism of Components,

Assembly and Design Environments

Interestingly, different industrial JavaBeans visual bean-build environments have taken different approaches on how to provide the user with assembly and design time control.

Two-window approach.
Sun's JavaStudio [*] [21] displays two windows simultaneously. One window shows the assembly picture while the other the design of the application. The windows are fully synchronized. The assembly window shows all beans by their icon representation with in- and out-ports, permitting the users to connect an out-port to some other in-port. The design window shows only visual beans in their visual representation, and hides the links. Thus the design window shows how the application would look at runtime. Moreover, the design window is an active running application, and you can test the application immediately. For example, you can enter text into a TextField component, push a Button component, examine the reaction to mouse-movements, and so on.

Split-window approach.
IBM VisualAge for Java 1.0 [22] displays only one window. But, within the displayed window, a dashed line denotes a special region. You can create visual beans only in that region, and non-visual beans only outside that region. (In VisualAge 2.0 and 3.0 this has been slightly modified.) However, you can pull the connectors (wires) across the (dashed lines) borders, because the two displays are practically the same window. Unlike JavaStudio, the design window is not active. To test the application, the system generates code, e.g., an applet, and compiles and runs it, a time consuming procedure.

Single-window approach.
In Sun's BeanBox [13], assembly and design are one and the same. This is because the BeanBox tool kit is not meant to be a development tool, but rather a ``proof of concept." It is a demo, testing, and prototype tool: it demonstrates the working of beans, it tests user-created beans, and it is a prototype that serves as an elaborated specification for industrial visual tools providers. The BeanBox also uses a mode-toggling approach, described next.

Mode-toggling approach.
In BeanBox 1.1, the user can switch back and forth from a runtime to a design time view by toggling two environment options:

1.
Enable/disable design mode. Design mode is enabled by default. When design mode is disabled, the BeanBox displays and behaves like the produced application would at runtime. This runtime mode is useful for testing the designed application without the extra BeanBox functionality as a developing tool. In disabled mode, the panel showing available beans is hidden. Selecting a component does not activate introspection, expose properties, or bring up customization panels; and all non-visual beans disappear. As a result, the application response time improves drastically.
2.
Show/hide invisible beans. This is a misnomer,[*] as it really means show or hide non-visual beans . When a non-visual bean is added to the BeanBox container, a label with its name is displayed. Otherwise, the user would not see the newly added bean and would not be able to customize its properties or connect it with other beans. Hiding invisible beans makes all non-visual beans invisible (even in design mode). This is intended to provide the user with a view of how the final design would look like, and still permit the fine-tuning manipulation of those beans that are visible.

Four combinations are hence possible:


next up previous NU-CCS-99-04.ps [ Readme | Copyright | Tutorial | Download | Feedback ]


Next: Manipulation and Representation of Up: Understanding the Assembly-Design Space Previous: Visuality, Symbolism of Components,

David H. Lorenz
3/17/2000