News

Early Draft released for JavaServer Faces 2.0 - Improved Interoperability for JavaScript Libraries

Posted by Dionysios G. Synodinos on Jun 13, 2008 06:41 AM

Community: Java
Topics: Javascript ,; JCP Standards ,; Web 2.0 ,; Web Frameworks ,; Specifications
Tags: OpenAjax Alliance ,; JSR 252 ,; JSR 314 ,; AJAX ,; JSF

The early draft for JSR 314 has been released for review under the Java Community Process Program. This JSR aims to update the 1.2 version of the JavaServer Faces specification to version 2.0. This next generation of JSF is an attempt to bring the best ideas in web application development to the Java EE platform and is already receiving positive feedback from the community, especially because of its improved AJAX support.

The key goals for this release of JSF, as summarized on the JCP page are:

The Expert Group will be harvesting existing ideas that:

Maximize the productivity of the web application development experience, for graphical IDE and command-line developers.

Minimize the complexity of maintenance of the web application during its production lifetime.

Make it easy to create responsive user interfaces through effective use of Ajax techniques. This includes enabling applications that have nearly all of the MVC controller UI logic and intra-page component interaction into the client, while keeping a sensible level of application logic on the server. Ideas that allow for graceful degredation when JavaScript is disabled or unavailable are also important.

Make it possible to expand the reach of your web application by continuing to support fully functional server based web applications that do not use JavaScript in the client.

Leverage modularity to expand integration opportunities between the JSF framework and other client and server side web application technologies. This would make it easier for a developer to use individual parts of JSF without being forced to use all of it. For example, the request processing lifecycle is useful even without the JSF View being present. As another example, JSF has a robust I18N and L10N capability. It should be possible to use this capability without using JSF components for your UI. A short way to characterize this is, "be mashup friendly".

Make it easy to expose your data by leveraging the Java Persistence API

Before the release of the JSF 2.0 draft, there have been several requests from the community for the addition of several new features. On his article on JDJ, Shay Shmeltzer, has presented his wish list for the next version of JSF, which can be summarized in the following points:

Standardize AJAX Integration into JSF
Simplify JSF Component Construction
Add More States
Introduce a New Component in the JSF Flow
Make Flows Reusable
Add Declarative UI to Business Components Binding

One of the issues that are addressed in the JSF 2.0 draft, is utilization of the Open Ajax Registry for coping with the lack of namespacing support from the JavaScript language. The Open Ajax Alliance which is an organization of vendors and open source projects that use Ajax, maintains the OpenAjax Registry, a centralized, industry-wide Ajax registration authority which keeps an industry-wide lists of Ajax runtime libraries to help prevent object collisions.

This Registry provides the following benefits:

The Registry helps prevent JavaScript and markup collisions and provides other benefits as follows:

Ajax library developers can use the Registry to:

make sure that their JavaScript global objects, runtime extensions (JavaScript and DOM), and library-specific markup do not conflict with names used by other Ajax libraries

coordinate their efforts to extend the JavaScript environment such that multiple libraries can share the same names and specifications for their extensions

Browser vendors can use the Registry to:

make sure that new built-in JavaScript features within the browser do not conflict with names already used within the industry

Ajax application developers can use the Registry to:

help ensure that any JavaScript globals used within their applications do not conflict with globals used by popular Ajax libraries

As specified in the JSF 2.0 draft:

There is a top level namespace javax that is registered with the Open Ajax Alliance:
Java Ajax: {
	namespaceURI: http://www.sun.com,
	version: "1.0",
	globals_to_approve:["javax"],
	comments: "Used in the JSF 2.0  specification.",
	specificationURI:"http://www.jcp.org/en/jsr/detail?id=316",
	email:  "jsfaces@sun.com"
}
To comply with the OpenAjax Alliance, libraries must register themselves using OpenAjax.registerLibrary() at the time when the JavaScript files are fetched and parsed by the browser's JavaScript engine.

Any page that intends to use the JavaServer Faces 2.0 JavaScript API must define a top level JavaScript object name javax, whose type is a JavaScript associative array. Within that top level JavaScript object, found in the OpenAjax Hub, there must be a property named faces whose value must be another JavaScript associative array. Within the faces JavaScript object there must be another JavaScript associative array under they key Ajax.
if (javax == null || typeof javax ==  "undefined") {
	var javax = new Object();
}
if (javax.faces == null || typeof java.faces ==  "undefined") {
	javax["faces"] = new Object();
}
if (javax.faces.Ajax == null || typeof  javax.faces.Ajax == "undefined") {
	javax.faces["Ajax"] = new Object();
}