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.
<!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>
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).
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.
Subscribe to Open Source Magazine Email News Alerts
Subscribe via RSS
