-C H A P T E R

C H A P T E R 7

Developing and Distributing Non-Extensible Model, Command and ContainerView Components

Recall that there is a fundamental difference between extensible and non-extensible components (see the earlier section Extensible vs. Non-Extensible Components, found in Chapter 2, Developing Components).

In the previous exercises, the development, distribution, and test cycle for five components was demonstrated. All but two of those were extensible components.

MyTextField (non-extensible DisplayField component).

ValidatingDisplayField (non-extensible DisplayField component).

SecureViewBean (extensible ViewBean component).

XMLDocumentModel (extensible Model component).

ValidatingCommand (extensible Command component).

What about the possibility of developing and distributing non-extensible Model, ContainerView, and Command components?

The short answer is that such components are possible, easy to develop, and easy to distribute. A non-extensible Model, ContainerView or Command component is a concrete Model, ContainerView, or Command that has been created within the IDE from an extensible Model, ContainerView, or Command component. It is no different from an application specific Model, ContainerView, or Command, except that is subsequently distributed in a component library JAR file with the express purpose of being incorporated into multiple applications, like any other distributed component. The distribution technique is common for non-extensible Models, ContainerViews, and Commands.

Why would someone develop and distribute non-extensible Model, ContainerView, and Command components?

Non-extensible Model, ContainerView and Command components provide several opportunities for component authors to deliver highly leveraged components to their component consumers. The discussion which follows only scratches the surface of this topic.

The most obvious opportunity provided by non-extensible Model, ContainerView, and Command components is the opportunity for component authors to move beyond delivering small building blocks to large reusable application and organization sized components. Non-extensible Model, ContainerView, and Command components typically form the top end of the component food chain. They allow component authors to deliver arbitrarily complex, very coarse grained components. If you consider DisplayField components to be the most fine grained components, the non-extensible Model, ContainerView, and Command components are at the opposite end of the component spectrum. Companies or organizations can create very sophisticated horizontal or vertical libraries of non-extensible Model, ContainerView, and Command components from which application developers can assemble applications out of very large, very reusable, very powerful building blocks.

For instance, non-extensible Model components can provide pre-packaged ready to use access to specific organizational data. Application developers can then simply define new Views and visually bind these applications specific Views to the pre-packaged Model.

Non-extensible ContainerView components can deliver pre-configured visual building blocks comprised of arbitrarily complex aggregations of smaller Views.

Non-extensible Command components can provide plug and play behavior.

Non-extensible components can be preconfigured to use other non-extensible components within the library. For example, a ShoppingCart ContainerView component can be pre-configured to use a companion non-extensible Model component.

Together, such preconfigured ContainerView and Model components provide ready to use already integrated visual presentation and data access. On top of that, the component author could preconfigure said ContainerView component to use one or more non-extensible Command components, thereby adding already integrated command behavior to the composite.

Organizations can create toolboxes comprised of collections of integrated non-extensible Model, ContainerView, and Command components. These toolboxes can be used internally to facilitate the rapid development of applications, or even delivered to partners as part of a broader business to business architecture.

The opportunity is boundless.

Develop a Non-Extensible Model, ContainerView, or Command Component

1. Develop the component within the Sun ONE Application Framework IDE as you would an ordinary Sun ONE Application Framework application object.

Use the appropriate Model, ContainerView, or Command wizard to construct the component.

Configure the component's properties.

Add arbitrary behavior to the component's Java class.

(ContainerView components only) Optionally add zero or more child view components to the ContainerView.

(ContainerView components only) Optionally associate zero or more JSP pagelets, to provide the rendering specification for the ContainerView component.

(Model components only) Optionally add zero or more model fields or model operations to the Model.

2. Create a ComponentInfo class for the new component.

This is highly recommended, though strictly speaking, not required.

A component specific ComponentInfo is recommended to minimally provide a component specific ComponentDescriptor. Optionally, the ComponentInfo can be used to specify any and all of the advanced component model features which are appropriate for non-extensible components.

Note - To visually create any non-extensible Model, ContainerView, or Command components within the Sun ONE Studio, you must construct the components within the context of an Sun ONE Application Framework application. That is to say, you must, first create an Sun ONE Application Framework application before you can leverage the IDE toolset to create any new non-extensible Model, ContainerView, or Command components. This is because the IDE toolset does not currently support a "library only design" mode. Future versions of the Sun ONE Application Framework IDE toolset might allow developers to choose between a "new library" or a "new application". However, currently, you can only leverage the Sun ONE Application Framework new object wizards within a Sun ONE Application Framework application. The fact that a component author will design these new components within an "application" has no bearing on the future independence of the components. The application merely provide the IDE toolset recognized context that allows the component author to leverage the complete visual IDE feature set during the authoring process. The ultimate end product of the component authoring will be the component's Java resources, which are totally independent of the application in which they might have been originally visually designed.

Assuming that you intend to create a new Sun ONE Application Framework application merely for the purposes of designing some new non-extensible Model, ContainerView, or Command components, the name of the application itself does not matter. One recommended approach is to consider the application as a convenient "test application" for your new non-extensible Model, ContainerView, or Command components. After you are satisfied with their performance within the test application, you add the new components to a component library JAR file.

The IDE Toolset will treat a Sun ONE Application Framework component's ComponentInfo Java source as "part" of the component. This means that the ComponentInfo Java source node will appear as a child of the component's primary node, just as the component's Java source appears as a child of the component's primary node.

This figure shows the Application component nodes showing explicit ComponentInfo Java source nodes.

Distributing a Non-extensible Model, ContainerView, or Command Component

1. Add a component element to the component library's complib.xml with one additional sub-element not discussed previously.

The component element must include a design-reference-resource sub-element.

The design-reference-resource sub-element must specify the location of the component's object definition resource.

2. Add the non-extensible component to a Sun ONE Application Framework component library JAR.

Include any classes and other component specific resources as you would for any Sun ONE Application Framework component.

Include the component's object definition file. This is the key distinction, as this is not required for the other components discussed in this guide.

Include any special "Additional Files" resources. See Automated Unpacking of "Additional Files" found in Chapter A, Component Library Structure.

Common additional file resources will include ContainerView components' associated JSP pagelet files.

An example of a non-extensible component entry in a complib.xml is as follows:

<component-class>mycomponents.MyFooCommand</component-class>

<component-info-class>com.iplanet.jato.command.BasicCommandComponentInfo</component-info-class>

<design-reference-resource>/mycomponents/MyFooCommand.command</design-reference-resource>

</component>

The emphasis on non-extensible Models, ContainerViews, and Commands being created within the IDE is intentional and important. All preceding component examples in this guide did not assume or require that the component types themselves be developed inside of the Sun ONE Studio. The visual use of the components within the IDE did require the use of the Sun ONE Application Framework enabled Sun ONE Studio, but the authoring of the component classes, ComponentInfo, complib.xml, and the preparation of the component library JAR files did not assume or require the use of the Sun ONE Studio.

However, with non-extensible Models, ContainerViews, and Commands that is not the case. They must be developed within the IDE because it is only the IDE which can generate the non-extensible component metadata, called the object definition file. In short, the key to distributing a non-extensible Model, ContainerView, or Command is to distribute its object definition file along with the class and ComponentInfo.

Can a component author mix non-extensible Model, Command, and ContainerView components in the same library with extensible Model, Command, and ContainerView components?

Absolutely yes. This is expected and encouraged.

After non-extensible Model, Command, and ContainerView components have been distributed in a Sun ONE Application Framework component library, how do application developer's make use of the components?

The non-extensible Model, Command, and ContainerView components within a given Sun ONE Application Framework component library will appear in the IDE toolset in exactly the same IDE contexts that the current application's non-extensible components appear. If this sounds tautological, it is intentionally so. Its points out that from the Sun ONE Application Framework IDE toolset's perspective all Model, View and Command objects are components. As far as the IDE toolset is concerned, it does not matter whether it discovers the components in a component library JAR or within the current application space.

The images below will demonstrate this point by showing that the various component choosers within the IDE toolset allow the application developer to choose freely and transparently between library supplied non-extensible components and application defined non-extensible components.

This figure shows the non-extensible Model component browser.This figure shows the non-extensible ContainerView component browser.This figure shows the non-extensible Command component browser.

The Object Definition File (non-extensible component metadata)

Suffice to say that both component authors and application developers should understand that the object definition files are produced by the IDE toolset and should be treated as first class application resources.

They should be preserved in source code control systems along with the conventional application resources.

They should not be edited by hand.

They have zero run-time value and need not be deployed to the servlet container.

They do need to be distributed with non-extensible Model, ContainerView, and Command components.

The following details of the object definition files are provided for information purposes only. These are implementation details of the Sun ONE Application Framework component model that neither component authors nor application developers are required to know

The Sun ONE Application Framework IDE toolset stores design-time state in XML format within its object definition files. The term object definition file is an arbitrary designation for these files. The object definition files:

Are XML files that conform to the Sun ONE Application Framework Model, ContainerView and Command DTDs.

Are the authoritative representation of Sun ONE Application Framework design-time state.

They are produced by the IDE toolset to capture the application developer design-time decisions (for example, object hierarchy declarations property configurations).

They are read by the IDE toolset to restore the design-time state across Sun ONE Studio sessions.

The IDE toolset generates Java code within the component's Java source file which is a Java equivalent of the design-time state stored in the object definition file. This code is generated into Sun ONE Studio Java source code editor protected blocks (for example, non-editable blocks).

Have file suffixes recognized by the Sun ONE Application Framework IDE toolset .model, .viewbean, .cview, and .command.

Have no run-time value at all.

The IDE toolset generates Java code within the application class which is a Java equivalent of the design-time state stored in the object definition file. Therefore, the object definition files have absolutely no run-time role or presence.