On the other hand, if you want to provide an alternative input mechanism for one property (like an enumerated list of valid choices), you can extend the PropertyEditorSupport class. The Molecule Bean in the BDK uses a property editor to provide a list of molecules it can display. (demo: edit menu option and the custom editor)
Using either of these mechanisms requires your Bean to provide a supporting class, along with the Bean itself. This second class implements the BeanInfo interface.
The BeanInfo interface allows you to describe your Bean in greater detail then reflection alone can do. You usually want to do this to provide your Bean integrator with less options, or more restrictive options, so the Bean is easier to work with. In order for the system to locate the BeanInfo for a Bean, you must name it after the Bean, with BeanInfo at the end of the Bean's classname. For instance, if your Bean was called Foo, the BeanInfo for the Foo Bean would be called FooBeanInfo. It isn't necessary to implement the entire BeanInfo yourself. The SimpleBeanInfo class provides a basis, then you just selectively override methods.
It's easy to get confused about the relationship between information provided by BeanInfo and information that's available through reflection.
Also, it is important to note that this information on BeanInfo (and the rest of the following material) is particular to the design mode. The classes that we implement here are not intended for use by the application developer. These classes are used by the beanbox tool that manipulates the bean. The bean class itself does not refer to any of these auxiliary beanbox classes so that it is not dependent on them and they do not have to be shipped with the bean in finished products.
As mentioned earlier, one usually doesn't implement the entire interface, but rather uses the SimpleBeanInfo convenience class that has empty implementations (returning null.)
A list of methods defined by the BeanInfo interface with a short description of each one:
| METHOD | Description |
| getAdditionalBeanInfo() | Returns any additional BeanInfo objects that provide additional information on the current bean. |
| getBeanDescriptor() | Returns the Bean descriptor object |
| getDefaultEventIndex() | Returns the default event index |
| getDefaultPropertyIndex() | Returns the default property index |
| getEventSetDescriptors() | Returns the event set descriptors |
| getIcon(int) | Returns the specified icon for the Bean |
| getMethodDescriptors() | Returns the method descriptors |
| getPropertyDescriptors() | Returns the property descriptors |
The key to using any of the more advanced features of the BeanInfo
class is the FeatureDescriptor class and its various subclasses.
As its name suggests, the FeatureDescriptor class provides information
about a feature. Features are properties, methods, events, and so on.
The subclasses of FeatureDescriptor:
Suppose you've created a SizedTextField Bean, the
SizedTextFieldBeanInfo class would provide the
Bean's BeanInfo. If you only wanted to display one property,
length, you could define that class as such:
These classes all work basically the same. You create a descriptor object for
each member you are trying to describe, and you collect all descriptors of a
feature set in an array and return it as the return value of one of the
BeanInfo methods. Thus, if you want to
restrict a builder tool to display less choices, you can override
the default behavior and implement your own BeanInfo.
Then, instead of the 17 properties of TextField, the only property displayed by the tool, would be the new length property. The SizedTextField class still needs to implement the set/getLength methods. Also, creating a custom BeanInfo does not prevent someone from calling the methods of the now hidden properties. The property accessor methods are still public. So, by using the Reflection API (or just knowing the method names), you can still invoke all the public methods. (Unless you also defined getMethodDescriptors() to limit these.)
Also, if you wanted to have the Bean have a space delimited name, instead of being all crunched together, you could add the following to the SizedTextFieldBeanInfo definition:
For another simple example of PropertyDescriptor, see the Nervous06 tutorial example
Since these descriptors are basically the same technique, I will not go into depth here.
Now let's see another demo of the use of MethodDescriptors: method choices
Note that to add a Customizer to your bean, you must supply a
beanInfo class and override the getBeanDescriptor method
as shown in both of the next two examples. The Customizer lets you set several
properties at once (no matter how fancy your property editor is, it is still
only responsible for allowing the user to set one property at a time.)
For your interest: Notice the difference in implementation of the PropertyDescriptor between the YesNoDialogBeanInfo.java: in Nutshell with its special editors:
and ChartBean ( newer ChartBean ) with
ChartBeanBeanInfo ( newer) in Core Java V2 with its special editors:
In summary: When any feature of your bean differs from the standard naming pattern, you must
Acme07Bean Do demo and show debug property (Also note the use of prinln for debugging)
Debug method (for debugging features): Example for Events
When an event is fired, the event source (the bean button) iterates over the list of listeners, sending each a notification of the ActionEvent.
To make debug a property, simply define setDebug and getDebug methods.
To enable a builder tool to learn about what Events a bean can generate, Properties that are exposed by a bean, and Methods it exports the bean must use "introspection". To accomplish this JavaBeans use a two-level approach:
Recently, JavaWorld contained two articles comparing the technologies. The first article is a strategic analysis of the two. The second article is a head-to-head comparison.
| Write Once, Run Anywheretm | java.beans package part of Core API |
| Component Reusability | Reuse Everywhere -- across platforms/tools/solutions Example: 3D Charting Bean - drop into any container, regardless of platform tool |
| Interoperability | Communicate with other component architectures Beans-ActiveX Bridge now beta, Beans-OpenDoc under development |
