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,
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:
- Enable design; show non-visual: assembly
time .
- Enable design; hide non-visual: design
time .
- Disable design; show non-visual: N/A
- Disable design; hide non-visual: runtime and testing.
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