Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

A first look at JavaServer Faces, Part 2

Explore JavaServer Faces components

By David Geary, JavaWorld.com, 12/27/02

  • Print
  • Feedback
.

Recall from Part 1 that JavaServer Faces (JSF) is conceptually a mixture of Struts (Apache's popular open source JSP framework) and Swing (Java's standard desktop application framework). Like Struts, JSF provides a well-defined lifecycle, shown in Figure 1, for processing requests.

Figure 1. The JavaServer Faces lifecycle. Click on thumbnail to view full-size image.



In Part 1, the JSF lifecycle was discussed in detail and therefore is not discussed here; however, this article refers to the JSF lifecycle, and Figure 1 is repeated for convenience.

Like Swing, JSF specifies a rich component hierarchy for implementing server-side user interface (UI) components. That hierarchy lets developers implement components from scratch with various renderers that can render different markup languages. The JSF component hierarchy and related objects such as validators, event handlers, and model objects are the focus of this article's following sections:



Read the whole series, "A First Look at JavaServer Faces:"



JSF components

JSF's component hierarchy separates JSF from other Web application frameworks like Struts. For example, both Struts and JSF have a set of custom JavaServer Pages (JSP) tags that represent HTML components, such as text fields and option lists, but the Struts tags generate HTML directly, whereas the JSF tags create server-side components that generate HTML. At first glance, the JSF approach might not have an obvious advantage until you realize that JSF components can be fitted with renderers that generate markup languages other than HTML. So, you can implement a renderer for your markup language of choice and associate that renderer with an existing JSF component. Also, the rich JSF component hierarchy makes it relatively easy to create custom components like a tree viewer or a query builder.

Figure 2 shows the class diagram for JSF components.

Figure 2. JSF UI components class diagram. Click on thumbnail to view full-size image.

JSF components implement the javax.faces.component.UIComponent interface, which specifies a whopping 46 methods that define the essence of a JSF component; Figure 2 lists only a handful of those methods. Luckily, your components can extend the abstract class javax.faces.component.UIComponentBase, which implements sane defaults for all UIComponent methods except for getComponentType(). That means you can implement a custom component simply by extending UIComponentBase and implementing getComponentType().

Each JSF component has:

  • A list of child components
  • A hashmap of attributes
  • One or more validators
  • One or more event handlers
  • An identifier for an optional renderer


All JSF components are potential containers, by virtue of a child components list maintained by every JSF component. That lets you nest components—even if they contain other components—inside other components. This crucial ability, which is the impetus behind the Composite design pattern, is routinely implemented by object-oriented graphical user interfaces (GUIs), such as Swing or VisualWorks Smalltalk.

  • Print
  • Feedback

Resources