Extensible Runtime Containment and Services Protocol for JavaBeans: - - JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档

Extensible Runtime Containment and Services Protocol for JavaBeans

5.0 Standard/Suggested Conventions for BeanContext Services

5.0.1 BeanContexts that support InfoBus.

The InfoBus technology is a standard extension package that is intended to facilitate the rendezvous and exchange of dynamic self describing data, based upon a publish and subscribe abstraction, between JavaBean Components within a single Java Virtual Machine.
A BeanContext that exposes an InfoBus to its nested BeanContextChild shall do so by exposing a service via the hasService() and getService() methods of type javax.infobus.InfoBus.
Thus BeanContextChild implementations may locate a common InfoBus implementation for their current BeanContext by using this mechanism to rendezvous with that InfoBus instance.
The Infobus 1.2 specification shall define a convenience mechanism provided by the InfoBus class to simplify the discovery mechanism for BeanContextChild instances nested within a particular instance of BeanContextServices.

5.0.2 BeanContexts that support printing

A BeanContext that wishes to expose printing facilities to its descendants may delegate a reference of (sub)type java.awt.PrintJob.
As the Java Network Printing Interface evolves additional specifications will be provided to expose it's facilities via the services mechanism.

5.0.3 BeanContext Design/Runtime mode support.

JavaBeans support the concepts of "design"-mode, when JavaBeans are being manipulated and composed by a developer in an Application Builder or IDE, and "Run"-mode, when the resulting JavaBeans are instantiated at runtime as part of an Applet, Application or some other executable abstraction.
In the first version of the specification, the "mode" or state, that is "design"-time or "run"-time was a JVM global attribute. This is insufficient since, for example, in an Application Builder environment, there may be JavaBeans that function, in "run"-mode, as part of the Application Builder environment itself, as well as the JavaBeans that function, in "design"-mode, under construction by the developer using the Application Builder to compose an application.
Therefore we require the ability to scope this "mode" at a granularity below that of JVM global.
The BeanContext abstraction, as a "Container" or "Context" for one or more JavaBeans provides appropriate mechanism to better scope this "mode".
Thus BeanContext's that wish to expose and propagate this "mode" to its descendants may delegate a reference of type java.beans.DesignMode:

public interface java.beans.DesignMode {
	void    setDesignTime(boolean isDesignTime);
	boolean isDesignTime();
}

Additionally, BeanContexts delegating such a reference shall be required to fire the appropriate java.beans.propertyChangeEvent, with propertyName = "designTime", with the appropriate values for oldValue and newValue, when the "mode" changes value.
Note that it is illegal for instances of BeanContextChild to call setDesignTime() on instances of BeanContext that they are nested within.

5.0.4 BeanContext Visibility support.

JavaBeans with associated presentation, or GUI, may be instantiated in environments where the ability to present that GUI is either not physically possible (when the hardware is not present), or is not appropriate under the current conditions (running in a server context instead of a client).
The first version of the JavaBeans Specification introduced the java.beans.Visibility interface in order to provide a mechanism for JavaBeans to have their "visible" state, or ability to render a GUI, controlled from their environment.
BeanContexts that wish to enforce a particular policy regarding the ability of their children to present GUI, shall use the java.beans.Visibility interface to control their children.

5.0.5 Determining Locale from a BeanContext

BeanContexts may have a locale associated with them, in order to associate and propagate this important attribute across the JavaBeans nested therein.
Therefore, BeanContexts, shall be required to fire the appropriate java.beans.PropertyChangeEvent, with propertyName = "locale", oldValue = the reference to the previous value of the Locale delegate, and newValue = the reference to the new value of the Locale delegate, in order to notify its Listeners of any change in Locale.
Setting and getting the value of the Locale on the BeanContext is implementation dependent.

CONTENTS | PREV | NEXT