-C H A P T E R

C H A P T E R 6

ConfigurableBeans (Non-Visual Components)

ConfigurableBeans are JavaBean types which have been explicitly designated as ConfigurableBeans in a component library manifest.

The IDE toolset automatically inspects all component library manifests and builds a dynamic list of ConfigurableBean types in memory. After the component manifest has been inspected, these types are said to be registered with the IDE toolset.

A snippet of the Sun ONE Application Framework Component Library manifest that declares some ConfigurableBeans is shown below.

As you can see, the designation is straightforward.

<configurable-bean>

<bean-class>com.iplanet.jato.model.SimpleModelReference</bean-class>

</configurable-bean>

<configurable-bean>

<bean-class>com.iplanet.jato.command.CommandDescriptor</bean-class>

</configurable-bean>

<configurable-bean>

<bean-class>com.iplanet.jato.view.command.WebActionCommandDescriptor</bean-class>

</configurable-bean>

Note that the technical name for these components is ConfigurableBeans. That is the name by which these entities are declared within the component library manifest. However, within the IDE toolset, application developers see the more developer friendly term Non-Visual Components.

This figure shows the Non-Visual Components node.

Only component authors need to understand that ConfigurableBeans and Non-Visual Components are essentially the same thing.

Technically speaking, the Non-Visual Components, which are visible as a sub-node of a ContainerView, are just a special case of the IDE toolset exposing ConfigurableBeans as nodes.

Formally speaking, all Non-Visual Components are ConfigurableBeans, but not all ConfigurableBeans are Non-Visual Components. There are, in fact, other cases of ConfigurableBeans being used within the IDE toolset which do not appear as explicit nodes. See ConfigPropDescriptors API - Value Policy.

How does the IDE toolset make use of the ConfigurableBean? What role do they play?

ConfigurableBeans are just ordinary JavaBean types which play a well defined but subtle role within the Sun ONE Application Framework IDE toolset. The Sun ONE Application Framework component model relies on ConfigurableBeans to complement the standard Sun ONE Application Framework components (Model, View, Commands).

Specifically, ConfigurableBeans complete the story begun by Sun ONE Application Framework ConfigPropertyDescriptors. Component authors add ConfigPropertyDescriptors to ComponentInfo whenever they need to specify a configuration property that they want to expose for design time configuration. Each ConfigPropertyDescriptor specifies a property "type". Application developers must edit/configure these properties within the IDE. Since the properties are typed, the IDE toolset can leverage this formalism, and provide a type specific editor. For example, if the configuration property type is Boolean.TYPE, the IDE will invoke the standard Boolean editor. This behavior is typical of any JavaBean aware IDE.

However, the Sun ONE Application Framework IDE toolset offers functionality above and beyond that of the standard JavaBean editor. This extra functionality involves the special treatment that the IDE toolset provides for Sun ONE Application Framework configuration properties whose property types correspond to ConfigurableBean designated types.

The IDE toolset uses a lookup algorithm to determine if the configuration property type corresponds to a registered ConfigurableBean type, and if so, it automatically invokes one of two special ConfigurableBean editors. These special Sun ONE Application Framework ConfigurableBean editors are shown below.

This figure shows the Dedicated ConfigurableBean editor (example property, Object Factory).This figure shows the Shared ConfigurableBean editor (example property, Model Reference).This figure shows the Shared ConfigurableBean editor displaying "existing" shared instance drop down list.This figure shows the Shared ConfigurableBean editor with "create new" shared instance selected.

The IDE toolset will invoke one of the two editors above based on a further subtlety in the ConfigPropertyDescriptor, known as the value policy. The details of value policy are beyond the scope of this section, for more information see ConfigPropDescriptors API - Value Policy.

For this section, it is sufficient to observe that while their layout is radically different, both of the ConfigurableBean editors provide a common core functionality. Both of these editors provide the application developer with a dynamic list of ConfigurableBean types which are assignable from the configuration property type. That is the key value add of the ConfigurableBean component. It is this mechanism which allows the IDE to seamlessly and dynamically incorporate new choices into properties that otherwise would normally be severely restricted.

For instance, the IDE will enable the editing of a configuration property of type CommandDescriptor with the ConfigurableBean editor that displays a dynamic list of CommandDescriptor sub-types. The application developer first selects the type of CommandDescriptor from the list, and then configures an instance of that type. The properties of the selected sub-type, of course, are dynamically exposed via conventional JavaBean logic.

Instead of being limited to a very plain vanilla CommandDescriptor editor which would be the case if left to the standard JavaBean handling, the Sun ONE Application Framework IDE toolset provides an unlimited opportunity for component authors to introduce custom ConfigurableBean types with their own sets of properties, and potentially, custom property editors. The IDE then transparently leverages these type/property sheet/editor combinations into the IDE as new offerings for simply defined properties. Effectively, the ConfigurableBean editor introduces an extra level of indirection that is extremely powerful and somewhat unprecedented. It is so unprecedented that it may take component authors some time to actually fully appreciate the opportunity that this offers them.

What is the relationship between Sun ONE Application Framework and the ConfigurableBean types?

ConfigurableBeans are a value added feature of the Sun ONE Application Framework component model.

Component authors are not required to utilize the ConfigurableBean feature. There is no formal notion of ConfigurableBean in the Sun ONE Application Framework run-time environment, or framework API. Rather, ConfigurableBeans are a feature offered by the component model to empower component authors and make the IDE experience richer for developers. Component authors are encouraged to come up with new ConfigurableBean types to either augment existing components, or enhance entirely new components.

The Sun ONE Application Framework Component Library does define quite a few ConfigurableBean types. Component authors should familiarize themselves with the usage of these ConfigurableBean types, as they provide the best illustration of the feature. Component authors should understand the manner in which the Sun ONE Application Framework standard components declare configuration properties which are satisfied by ConfigurableBean types. In addition to writing new components, component authors should understand that they can also immediately augment the existing Sun ONE Application Framework components by providing additional ConfigurableBean types that are appropriate for the already defined Sun ONE Application Framework configuration properties identified below.

Following is a table to help guide your review.

ComponentInfo	ConfigPropertyDescriptor	ConfigBeans Assignable From Property Type
BasicDisplayFieldComponentInfo	ConfigPropertyDescriptor( "modelReference", com.iplanet.jato.model.ModelReference.class)	com.iplanet.jato.model.SimpleModelReference
BasicCommandFieldComponentInfo	ConfigPropertyDescriptor( "commandDescriptor", com.iplanet.jato.command.CommandDescriptor.class)	com.iplanet.jato.command.CommandDescriptor com.iplanet.jato.view.command.WebActionCommandDescriptor com.iplanet.jato.view.command.ExecuteModelCommandDescriptor com.iplanet.jato.view.command.GotoViewBeanCommandDescriptor
ObjectAdapterModelComponentInfo	ConfigPropertyDescriptor( "objectFactory", com.iplanet.jato.model.object.ObjectFactory.class)	com.iplanet.jato.model.object.factory.SessionAttributeFactory com.iplanet.jato.model.object.factory.ApplicationAttributeFactory com.iplanet.jato.model.object.factory.RequestAttributeFactory
BasicChoiceDisplayFieldComponentInfo	IndexedConfigPropertyDescriptior( "choices",com.iplanet.view.Choice.class)	com.iplanet.jato.view.SimpleChoice

Configurable Bean Example: CommandDescriptor

The obvious Command components are the extensible Command components. Extensible Command components are custom implementations of the com.iplanet.jato.command.Command interface, which are intended for specialization by application developers. The specialization by application developers will usually consist of application developers adding custom logic to their application specific Commands. Command objects have minimal formal structure, being arbitrary implementations of a very simple interface, com.iplanet.jato.command.Command. Therefore, there is not as much of an opportunity to formalize the construction of new Command types within the IDE beyond the specification of properties.

Additionally, the Sun ONE Application Framework offers other Command component opportunities. To understand this opportunity, it is necessary for the component author to fully understand the formal role of CommandDescriptors. Effectively, CommandDescriptors are configurable beans that allow for the design-time configuration of Command object instances.

The Sun ONE Application Framework and the IDE toolset utilize CommandDescriptors to allow the application developer to configure the usage of Command objects. That is to say, there is a formal uses relationship between CommandFields and Command objects and this relationship is mediated by CommandDescriptors. CommandFields are Views (for example, Buttons and HREFs) which invoke Command objects when activated. The application developer specifies which Command object will be invoked when the CommandField is activated via the field's Command Descriptor property.

A CommandDescriptor is a Sun ONE Application Framework object that encodes the information needed at run-time to construct a particular instance of a Command class and invoke it. Minimally, the CommandDescriptor specifies which Command class should be instantiated at run-time. The CommandDescriptor also allows developers to specify Command specific parameterized values. For instance, it is very common for a single Command object to be associated with multiple CommandFields. Each CommandField would employ a distinctly configured CommandDescriptor to direct and influence the execution of the Command. For more detailed information on this subject, see the Sun ONE Application Framework Developer's Guide.

This figure shows the CommandField with CommandDescriptor property selected.This figure shows the CommandDescriptor editor.

Given the role of the CommandDescriptor, the opportunity exists for component authors to create a very rich Command component story through the combination of non-extensible Command components and component specific CommandDescriptor classes.

For instance, a component author can create and distribute a non-extensible Command component plus a custom CommandDesciptor class designed to allow developers to visually configure the invocation of the non-extensible Command component. The custom CommandDescriptor, itself, can be distributed as a ConfigurableBean component. ConfigurableBeans are visually exposed by the IDE toolset as Non-Visual Components.