Build Custom JSF Components (Continued)

The bad. The bad thing is that faces-config.xml and TLDs are not very expressive and cannot convey interesting constraints such as valid values, or component enumerations. An example is the Oracle ADF Faces component <af:panelLabelAndMessage>. This component has an attribute called messageType. The valid values for this attribute are "error", "warning", "info", and "none". Unfortunately, there is no way in faces-config.xml to express that constraint. The faces-config.xml file also cannot indicate relationships between components, such as what would be a valid child for a particular component—for example, a Table component might only accept a Column component as a valid child. These shortcomings can be dealt with by providing these constraints and relationships in design-time metadata.

The ugly. What could turn ugly is if tool vendors define their own proprietary ways of providing design-time metadata. Tool vendors are already asking for additional metadata from component authors so that components can fully utilize the design time, which will lead to component authors providing proprietary solutions for each tool vendor.

The hope. The hope is that the JSF community can agree on standard design-time metadata and that component authors will invest in providing metadata for their components. The most likely way of defining such a standard is through the Java Community Process (JCP). Oracle is working with other JCP members with the goal of proposing a new JSR that would define a standard set of design-time metadata items for JSF components and a mechanism for providing such metadata.

Although the faces-config.xml language allows a component author to express a great deal of information about their components and renderers, it only has standard syntax for expressing a very minimal set of design-time metadata (mainly display-name, description, and icon). Fortunately, the faces-config.xml language is designed with convenient extension points that can be used to hold additional information.

Strong Community
As previously discussed, there is not yet a standard mechanism for supplying additional design-time metadata. However, one proposed solution would utilize the extension points in faces-config.xml (see Listing 1). If you are interested in this issue, there is a thread on the Sun's JavaServer Faces Technology forum devoted to discussing design-time metadata for JSF components.

A crucial ingredient for the continuation of JSF's success and progress is a strong community. If you look at what ASP.Net has done and evaluate what makes this proprietary framework so successful, there is one thing that always pops up: the ASP community. Its community sites have forums with hundreds of daily posts as well as tutorials and content that are updated daily. There are component galleries with free hosting of custom components, which are integrated with the development tools. There are also free versions of basic tools supporting ASP development.

Some of this type of groundwork has already started with projects such as MyFaces and information sites such as JSFCentral, but this is not enough. We cannot hope that a small group or a single person can provide us with a complete set of community sites including daily posts, tutorials, and contents. Now is the time to get involved in Faces!

The JSF community needs one or more neutral hosting sites that provide content such as tutorials, forums, and announcements—and, of course, component galleries. Another area in which the community can provide help in is testing tools. In the spirit of Cactus and JUnit, the community could provide testing tools with a different approach, such as test components and not markup, and send simulated events. For anyone eager to get involved, this possibility would make a good open source project.

Skinning and themes are areas that noncoders could ideally participate in. Noncoders could provide style abstractions to mirror component abstractions using styles, icons, text/translations, and templating.

There is a future beyond HTML; eventually, component authors will provide higher-level components with better customization. These components will be based on other client-side technologies, such as DHTML, SVG, Flex, XUL, and Web Forms (see Figure 2).

The message here is, think components, not markup! JSF is not exclusively for HTML, it is not exclusive to hard-core developers, and it is not exclusive to business developers. There are plenty of opportunities for all types of developers. Finally, don't forget the metadata, and make sure you get involved early in the JSF community.

About the Author
Jonas Jacobi is a senior product manager for JDeveloper at Oracle.