The JavaBeans APIs cover five main areas:
- Event handling. These APIs allow one
component to deliver events to other components.
The AWT team has extended the AWT event mechanism to make it more flexible,
and to make it easier to connect arbitrary event sources to arbitrary event
sinks. We have also adopted this new AWT event model for JavaBeans.
- Properties. Properties represent discrete
attributes of a component such as its foreground color, its font, etc.
We have defined standard design conventions for components that wish
to expose properties.
- Persistence.
These APIs allow JavaBeans components to be stored away as part of the state of
their parent container. The default persistence mechanism is the
automatic Java serialization mechanism, but we are also designing a more
sophisticated persistence API for those components that need more explicit
control over their persistent state.
- Introspection. A key goal of the JavaBeans APIs is
to use the Java type system to define components. To allow application
builder tools to analyze components we have developed APIs to let them
study the Java types of components. These APIs exist at two levels.
JavaSoft has defined low level APIs to allow tools to learn about all
the methods, interfaces, variables, etc, associated with a Java class.
In addition, as part of the JavaBeans APIs we provide a higher level
inspection API that uses this lower level API and a set of
standard design patterns to determine which
events, properties, and methods are exported by a given Java Bean. We
also provide APIs to allow a bean to override this default analysis.
- Application Builder APIs. JavaBeans components
will have two main roles. Their normal role is when they are used as
active components inside a running application. But they have an
important second role when they are used inside an application builder.
We are defining APIs so that beans
can provide custom component editors known as customizers for
use with application builders. We are deliberately allowing a bean's
customizer be be separate from the bean proper, so that the customizer
is only needed during application development, and need not be
downloaded when the resulting application is run.
|
|
Print-friendly Version
