This article is based on, and contains excerpts from, the book Pro JSF: Building Rich Internet Components by Jonas Jacobi and John Fallows, published by Apress. Book is now available on fine bookstores and Amazon as of February 25, 2006.
JavaServer Faces (JSF) standardizes the server-side component model for Web application development but doesn't standardize the presentation layer at the browser. In a series of articles we are going to look at how JSF can fulfill new presentation requirements without sacrificing application developer productivity building Rich Internet Applications (RIA).
Consumer Requirements
It's always the end user who feels the effect of any chosen technology, especially at the presentation layer. The end-user experience should be top priority for any developer building applications, whether they are Web applications or desktop applications. End users demand feature-rich and highly interactive user interfaces.
Introduction to Rich Internet Technologies
Web application developers today are faced with higher demand for richer functionality using technologies such as HTML, CSS, JavaScript, and DOM. These 
technologies were not developed with enterprise applications in mind and, with increasing pressure from consumers to provide applications with features not fully described or supported by these technologies, developers are looking for alternative solutions or extensions to these standards.
From a combination of both consumer requirements and developer needs, a new breed of Web technologies has evolved. Often referred to as Rich Internet Technologies, these technologies enhance the traditionally static content provided by Web applications.
In the absence of sufficiently powerful standards, new technologies such as Mozilla's XUL, Microsoft's HTC, Java applets, Flex, and OpenLaszlo have emerged to meet the requirements. Such technologies support application-specific extensions to traditional HTML markup while still leveraging the benefits of deploying an application to a central HTTP server. XMLHTTP has also returned under a newly branded name, AJAX (Asynchronous JavaScript and XML). Applications built with these technologies are often referred to as Rich Internet Applications (RIA).
In this article series we are going to focus on AJAX and XUL to illustrate the potential that JSF brings to the JavaEE developer.
AJAX
AJAX has gained momentum primarily due to the XMLHttpRequest browser object, which supports asynchronous communication with any business services used by the Web application. Popular sites such as Google Mail and Google Suggest use AJAX to deliver RIA.
With the XMLHttpRequest object, developers can now send requests to the Web server to retrieve only the data needed and use JavaScript to process the response.This ability to reduce the amount of data transferred between client and Web server reduces the bandwidth to a minimum and saves processing time on the server since most of the processing is done on the client using JavaScript.
It is important to note that the XMLHttpRequest object, although widely used, could at best be called a "de facto" standard, since most browsers, including Firefox, Inter-net Explorer, Opera, and Safari, support it. It is also worth noting that the XMLHttpRequest object is not exclusive to AJAX; potentially the XMLHttpRequest object can be used by any HTML/XML-based Web technology such as XUL or HTC.
Desktop vs Web
Traditional Web applications are in most cases slower than their counterpart desktop applications. With AJAX we can now send requests to the Web server to retrieve only the data needed and use JavaScript to process the response, which leads to a more responsive Web application.
A typical AJAX application leverages standard HTML/XHTML at the presentation layer and uses JavaScript to dynamically change the DOM. This creates an effect of "richness" in the user interface with no dependency on additional browser plug-ins.
Mozilla XUL
XUL (pronounced zool) was created by the Mozilla organization (Mozilla.org) as an open source project in 1998. With XUL, developers can build rich user interfaces that may be deployed either as "thin client" Web applications, locally on a desktop, or as Internet-enabled "thick client" desktop applications. To fully provide the consumer with a rich user interfaces, XUL needs to execute in the Mozilla Gecko Runtime Environment (GRE). There are many examples of applications using XUL, including the Firefox browser, the Thunderbird e-mail client, and numerous plug-ins to each.
XUL Structure
The base idea behind XUL is to provide a markup for building user interfaces much like HTML, and to leverage technologies such as CSS for look-and-feel and JavaScript for events and behavior. There are even APIs available to access files systems and Web services over the network. As an XML language, XUL can be also be used in combination with other XML languages, such as XHTML and SVG.
XUL Components
XUL comes with a base set of components that are available through the Mozilla GRE, and has the added benefit of not needing to download components to display an application in the browser. You can also design your own components with XUL; these will need to be downloaded on request and cached in the browser.
XUL uses a language called XBL (eXtensible Binding Language) to define new components. XBL is also used to bridge the gap between XUL and HTML, making it easy to attach behavior to traditional HTML markup.
Listing 1 is a sample XUL file that embeds XUL elements and standard, name-spaced HTML elements.
XUL Event Handling
Using XUL event handling is not that different from using HTML event handling. The GRE implementation supports DOM Level 2 (and partially DOM Level 3) and is virtually the same for HTML and XUL, and changes to the state and events are propagated through a range of DOM calls. XUL elements come with predefined event handlers, much like the event handlers provided with the standard HTML elements (see Listing 2).
As in HTML, developers can use JavaScript functions located in external libraries, or embedded in the page.
<script type="text/javascript"src="http://
www.bob.org/js/myscript.js">
There is a large set of built-in XUL components, each with its own set of event handler attributes. For example, the XUL window element delivers events such as load and paint.
Creating Custom XUL Components Using XBL
XBL is an XML language that allows developers to extend XUL by adding "custom" components to the extensive set of existing XUL elements. In XUL, developers can define the look and feel using CSS, and they can define the behavior using XBL.
Developers can look at XUL as the "implementation" that comes with a pre-set of components, or tag libraries that can be used to build a user interface, much like the JSF Reference Implementation. XBL is the language developers use to extend XUL components and enable integration with HTML, in much the same way that Java is used to extend JSF components.
XBL Structure
An XBL file contains a set of bindings, each describing the behavior, properties, and methods of an XUL component.
A quick look at Listing 3 shows the root <bindings> element containing two binding elements. A <bindings> element can contain any number of <binding> elements. The namespace in the <bindings> element defines which syntax will be used, and in Listing 3 it is XBL - xmlns=http://www.mozilla.org/xbl. The file also contains a combination of XUL and HTML elements <xul:text/> and <html:input/>. This is extremely useful for simplifying development by encapsulating several components as a single, reusable component. The xbl:inherits attribute allows the text element to inherit values from the bound element by defining a variable called name and assigns it to the value attribute. If no value is defined when the component is used in a page, the text field's value will default to "Guest".
The ID attribute on the binding element (in Listing 3 "welcome" and "bye") identifies the binding. Using CSS, a developer can assign a binding to an element by setting the -moz-binding URI property to reference the binding inside the XBL document.
Note: The way custom behavior can be attached to an HTML element has been submitted as a proposal to the W3C organization - "A Modular Way of Defining Behavior for XML and HTML" (www.w3.org/TR/NOTE-AS) by Netscape Communications Corp.
bob\:welcome
{
-moz-binding: url('bob-xbl.xml#welcome');
}
In the above sample, the CSS selector for the bob:welcome element has the -moz-binding set to point to an XBL file named bob-xbl.xml and refers to a specific binding with ID welcome in the XBL file. This is similar to how anchors are used in HTML files.
In the above HTML sample the bob.css stylesheet has been attached to the HTML document, and there is one element <bob:welcome name="Bob"></bob:welcome> inserted in the page. One cool feature to using XBL's encapsulation of behavior is that it creates a document tree within the scope of the custom component that is separate from the main HTML page. This means that the XBL component markup is not "exploded" into the main document, losing encapsulation (see Figure 1).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" >
<html>
<head>
<link rel="stylesheet" type="text/css" href="bob.css" >
<title>Mozilla XBL Example</title>
</head>
<body>
<div><bob:welcome name="Bob" ></bob:welcome></div>
</body>
</html>
The direct benefits of encapsulation are full control over both the behavior and the look-and-feel, but without exposing any internal implementation details (see Figure 2).
Adding Functionality to an XBL Binding
XBL can be used to add new fields, properties, and methods to XUL elements. A field is a simple container that can store a value that can be retrieved and set. A property is slightly more complex and is used to validate values stored in fields or values retrieved from XBL-defined element attributes. Since the property cannot hold a value, there is no way to set a value directly on a property without using the onset or onget handlers. By using these handlers, a developer can perform precalculation or validation of the value being retrieved or modified (see Figure 3).
Methods are object functions such as window.open(); and allow developers to add custom functions to custom elements. In the XBL file, fields, properties, and methods are defined inside an implementation element that is a child of the binding element (see Listing 4). Developers can use the getElementById function to first locate a custom element before accessing custom properties and methods.
In Listing 5, an HTML button has been added that triggers the onclick event handler. The onclick event handler will execute the assigned script - alert(document.getElementById('welcome').bob) - and display the value of the field called bob.
Handling Events in XBL
In XBL, developers can add event handlers directly to the individual XUL elements inside the content element, e.g., <xul:button label="Press me!" oncommand="alert('welcome')" />. Sometimes it's useful to add an event handler for all the child elements of the content element. In XBL, this can be done by adding a handler element. Each handler defines the action that will be taken for a particular event triggered by any of its content elements.
In XBL sample shown in Listing 6, a button has been added to the welcome binding and one handler has been added to capture all click events in the scope of the welcome binding.
Why Would JSF Be of Any Help?
Of the two technologies used in this article, only XUL is designed to support reusable components in Web applications. XUL allows for the encapsulation of HTML, CSS, and JavaScript into a single component that can be reused by the application developer. AJAX, on the other hand, solves the asynchronous communication to the server that can be used to provide end users with a very responsive UI.
These technologies solve most of the consumer requirements, but are still lacking in support for the application developer. We need a standard way to define Rich Internet Applications that are deployable over the Web without vendor lock-in.
The WHAT (Web Hypertext Application Technology) group is working on a standard tag library for HTML extensions that can work on any browser. Meanwhile, developers are falling back to the lowest common denominator - HTML - and using scripts to build dynamic Web applications, e.g., AJAX. However, this approach of developing Web applications has one severe drawback - there is no good reuse model or easy integration with existing server-side logic.
JavaServer Faces defines a standard component model to server-side Web application development. By integrating JavaServer Faces with XUL and AJAX, we can provide a highly interactive Rich Internet Component suite that also delivers a standard reuse model for Web application developers.
Why a Component Model?
Using components instead of markup is an effective model that allows application developers to build Web applications with prefabricated blocks of functionality without concern for implementation details. Over time, the component author can maintain the internal implementation without adversely impacting the application developer.
Cross-Platform Support
Cross-platform support is critically important for today's technologies, never mind what tomorrow might bring. Consumers are already requesting increased support for platforms such as handheld devices, telnet clients, and instant messaging.
In most cases, applications need to be designed to use features of a specific platform, which in turn is time consuming and costly. As each new platform is added, the time and cost can increase significantly.
For the two technologies previously mentioned in this article, one claims that it has cross platform support - Mozilla's XUL. This is partially true; you can deploy a XUL application to any operating system that the Mozilla platform (GRE) supports.
You could also argue that AJAX provides cross-platform support, but it is the provider of the AJAX solution that needs to ensure that every browser-specific quirk is supported.
So, although you have plenty of environments to deploy to, there is no true solution that has full cross-platform support.
With Imagination as the Only Limit
JSF standardizes the server side for the application developer now, while we wait for the presentation layer at the browser to standardize for component developers.
JSF separates the user interface from the application, making it possible for the component author to change the presentation layer without tampering with the application. This is not solving the cross-platform issue or the extensibility of HTML, but it will help application developers build Rich Internet Applications in an unswervingly standard way.
A JSF component developer could take advantage of XUL's presentation layer and AJAX for communication, creating a highly interactive component. If the client does not support XUL, the application can dynamically fall back to a non-XUL solution. The application developer will still be able to build one application supporting multiple rendering technologies with one common programming model - JavaServer Faces.
A Page in JSF Supporting XUL and AJAX
The JSF sample shown in Listing 7 illustrates what a page developed with reusable JSF components leveraging XUL and AJAX as rendering technologies can look like.
Apart from the obvious namespaces, the sample contains one namespace that maps to a custom component library - xmlns:bobh=" http://www.bob.org/jsf/html" - and a custom component - <bobh:inputDate ..."/>.
The source of the page is not that different from what we have seen so far with XUL or AJAX, but the main difference is that the Web application developer will not need to learn two ways of supporting Rich Internet Applications in today's browsers.
Summary
This article provides some insight into two of the market's leading view technologies for Rich Internet Applications (RIA) - XUL and AJAX. These technologies have proven that they are more than capable of providing the end user with a highly rich and responsive user interface. We have also touched on the issues with these technologies such as platform support, being non-standards based, and maintenance.
Looking ahead, the potential for JavaServer Faces as a UI component technology is without boundaries. Component developers can provide the community with a wide range of components supporting technologies from HTML to XUL, wireless, and even character-based solutions with the imagination as the only limit.
In future articles, we are going to discuss how to build reusable JSF components that leverage AJAX and XUL.
This article is based on, and contains excerpts from, the book Pro JSF: Building Rich Internet Components by Jonas Jacobi and John Fallows, published by Apress. Book is now on bookstores and Amazon as of February 25, 2006.