Tool Compliance in JavaBeans 1.0
The document describes what a builder tool should do in order to
comply with the JavaBeans architecture.
This document is targeted at a variety of tool vendors that want
to conform to the JavaBeans 1.0 architecture. Specific tools include:
- RAD (Rapid Application Development) tools
- Visual Applet builders
- Bean builders
- Applications that can be extended via JavaBeans components.
Different types of tools may want to use different features of
the JavaBeans architecture.
Our intention is to specify only as much as necessary so that
tool vendors can be as creative as possible in satisfying the
specific needs of their customers.
The requirements listed in this document are organized by general area.
Acquiring Beans
-
JAR files are the standard mechanism for delivering Beans in JavaBeans1.0;
the tool must accept Beans delivered as a JAR file.
-
Beans can be described both as classes (.class files) and as persistent
representations of Bean prototypes (e.g. .ser files) within that JAR.
The contents of a JAR file are described using the optional MANIFEST
file.
-
Classes in a Bean delivered in a JAR must be able to access resources
delivered in that JAR file using the getResource() APIs.
-
After importing some Beans into the builder (delivered intially as
a JAR file), the builder can choose not to load from the
JAR file directly and instead it may store the information
initially present in the JAR file elsewhere.
-
Support for invisible Beans is strongly encouraged but it is
not mandated (e.g. your application may support only a WYSIWYG
mode).
If invisible Beans are supported, the presentation of a Bean may, or not,
differ from that of visible Beans.
Generating Beans
-
If the tool generates new Beans for exporting to other tools,
it must be as a JAR file.
Generating Applets and Applications
- The JavaBeans1.0 architecture does not specify the format for
applets or applications generated by composing Beans.
Of course, it the builder tool generates a composite Bean,
the Bean will have to conform to the JavaBeans architecture.
Exposing information in a JAR file:
-
The JavaBeans 1.0 architecture defines how to determine what
are the Beans packaged in a JAR file.
-
The builder tool can select a subset (maybe all) of
these Beans as the Beans available to the tool. In doing this
selection, the builder tool may choose based on some information given
in the MANIFEST, or some other mechanism.
-
If the content of the JAR file is shown to the user,
all the Beans in it must be shown, but those that are not made available
to the tool can be indicated as so in some way (e.g. by being
non-selectable).
Exposing information on a Bean
Properties
-
If the tool provides a way to show the set of properties of the Bean,
it should show at least all the non-expert non-hidden properties.
This may be shown in a property sheet, or in a different mechanism.
-
The builder tool may choose to present expert properties, or may
choose not to.
-
A Bean provides information on its customizer through BeanInfo.
If there is a customizer for a Bean, the builder tool
must make this customizer accesible to the user.
Of course, the builder tool may also present other mechanisms to access
the information on the Bean.
-
If a tool presents a properties of a Bean and the property is not read-only,
then the tool must provide
a mechanism to edit this property.
The JavaBeans 1.0 architecture provides PropertyEditors to
present and edit these properties.
A PropertyEditor may provide one or more of the following
mechanisms to edit the property value:
- as tag
- as text
- as paintable
- via a customEditor
If the PropertyEditor associated with a property provides
a customEditor, that customEditor must be made available to the
user; in that case, none of the other mechanisms need be made
available to the user (although tools may choose to make them
available).
-
If no customEditor is available and at least one of
tag, text, paintable are available
in a PropertyEditor the builder must make the property available
through one of them. If more than one is available, the builder tool
may choose to present one or more of them.
-
Indexed properties are less frequent and more complex to interact
than non-indexed properties. The builder tool may choose not to
provide information on indexed properties (in a manner analogous
to expert properties).
Events
-
The builder tool must expose at least all non-expert non-hidden events
that the Bean may fire.
-
The builder tool can choose whether to present expert events
to the user.
Methods
-
There is no requirement for the tool to present any
information on the methods available on a Bean.
Event Sources, Even Sinks, Connections
-
A builder tool may provide a mechanism for connecting an event fired
by a Bean to another Bean "capable" (as defined in the next bullet)
of receiving it.
-
A connection may or not involve an adaptor; the latter is when the
sink Bean directly supports the sourced event.
Tools may be as inventive as their users need in supporting different
types of adaptors.
-
If a builder tool supports connections, then it must support
connections between instances of Beans delivered in one JAR file to
instances of Beans delivered in a different JAR file, even though they
use interfaces that are not provided in the system classes (some
people use the term non-standard for this).
Specific API usage
-
The builder tool must use only "Beans.instantiate()", "Beans.getInstanceOf()",
and "Beans.isInstanceOf()" when instantiating and casting Beans.
-
The builder tool must instantiate Beans that are applets via
"Beans.instantiate()". The applets are "start()"ed by the tool
after insertion into an AWT container.
-
The introspection capabilities of the tool must be equivalent to
calls on Beans.instrospect(), although a tool may choose
to modify its performance by caching or other techniques.
-
The builder tool must use serialization and/or externalization
to store Bean prototypes that are to be made available outside of
the builder tool (be that to other builder tools, or in uses like
the OBJECT tag).
-
When making a Bean persistant into some storage, the connections
between that Bean and other external Beans (not stored in that
storage) must be removed.
Back to JavaBeans Advisor #5.
Eduardo Pelegrí-Llopart
(pelegri@eng.sun.com).
Last update May 5th, 1997.