Build Custom JSF Components (Continued)

Component developers. Components, components, components: these are the golden nuggets that will make or break the success of JSF. Some vendors are already producing components for external use and for open source communities such as MyFaces (see Resources). But, for JSF adoption to increase we need more components—lots of them—and with richer functionality.

The dearth of existing components and the need for richer component sets mean that getting into the business of providing JSF components is a good opportunity. JSF also allows component authors to sell components based on a recognized J2EE-standard framework (instead of trying to convince customers to use a homegrown framework). Besides the business aspect of creating JSF components, there are also benefits to creating components by using JSF. JSF provides built-in support for aspects that are hard and cumbersome to implement, such as event handling, state saving, expression language, and a standard way to make custom components extensible.

Tool developers. Tool developers need a formal standard that not only makes life easier for end users but also allows the developers to design and develop tools that will ease development of Web applications, or as they are called in this early part of the twenty-first century, J2EE applications.

As you are probably aware, JSF uses different classes for providing component functionality and for rendering the component. Before getting your hands dirty building your first set of components, search the Web for existing components.

There should be a fair amount of components already out there, and in most cases, you can probably get away with writing a new renderer for an existing component. If the component you are looking for cannot be found, it is time to build your own. To build a new component, you should make sure it has distinct server-side behavior and introduces a new behavior, functionality, or definition. If the component exists and you need a new appearance, you just need to create a new renderer (see Figure 1).

Good and Bad of It
An example of good separation between behavior and appearance is the UISelectOne component provided by the JSF Reference Implementation. This component has a distinct behavior and three different renderer types: ListBox, Radio, and Menu. Potentially, you can add other types of renderers that have different appearances but the same behavior.

What distinguishes a good component from a bad component? A good component should have generic properties, event listeners, and specific behavior. The component should not contain markup-specific attributes, such as the "href" attribute; should not write markup or get request parameters; and should work with server events, not client events. It is important to isolate the presentation information from the underlying server-side component (see Table 1).

In addition to the Table 1 information, using JSF facets enhances business developers' user experience developing applications with JSF components. A facet is a kind of child component that has a specific purpose defined by its name. A facet can be viewed as an empty placeholder that can take one child component. A parent component can have multiple facets; an example is a component called panelPage provided by Oracle's ADF Faces component set. This component uses facets to render its children in predefined locations such as the corporate logo (CORPORATE_BRANDING facet) or the copyright statement (COPYRIGHT facet).