LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

High Performance Computing Linux Financial Markets
4/19/2010
New York City
Flagg Management

Informix User Conf.
4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

Does Windows cost Microsoft opportunities?
Microsoft's decision to focus .NET on Windows is stifling innovation due to the specter of...

Going 'all in' on .NET as default runtime
Programmers for Windows Phone 7 will need to use Silverlight and XNA for development

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

JSF 2.0 Faces Disjointed Components


Next version of JavaServer Faces aims to reduce configuration headaches

By Alex Handy
December 26, 2007 — 
Sometimes, the cure for one’s woes is a hard look in the mirror. JavaServer Faces is facing up to its own configuration problems with JSR 314, the specification for JSF 2.0.

The project, under the auspices of the Sun Microsystems-driven Java Community Process, already has five primary goals: make custom components much easier to develop, add first-class AJAX support, incorporate a page description language based on Facelets into the core JSF specification, reduce the required configuration, and provide for better compatibility among JSF component libraries from different vendors.

Roger Kitain, staff engineer at Sun, and Ed Burns, senior staff engineer, are co-specification leads on JSR 314. The pair hopes to make JSF a clearer path between the Web and the complicated back-end systems and capabilities Java provides. That effort will begin with the simplification of the configuration process for JSF applications.

“One of the problems people have had with JSF is that when they sit down and develop custom components with JSF, there are different things you have to [configure] in different areas,” Kitain said. “You have to remember these different areas to piece those together, like component render associations. We're looking to simplify all that by making fewer areas to keep track of when developing this stuff.”

That means adding in the ability to configure components inside of annotations. It also means having fewer XML files scattered around and consolidating configuration files in easier-to-find places, said Kitain.

For component developers, mixing and matching the capabilities of various JSF snippets has also been difficult, said Burns. “The reason [third-party components] are not playing well together is that the JSF 1.2 specification, and earlier, simply did not say what to do [when] loading…static resources like scripts or style sheets. It didn't say what to do for partial tree traversal via AJAX, nor for persistence. Each of those component libraries had to invent their own solutions to do that,” said Burns.

Kitain and Burns also stated that those components would need to be rewritten to work with JSF 2.0.

In a world where the Google Web Toolkit (GWT) has made Java-to-Web design as easy as pointing and clicking, Burns and Kitain remain confident that JSF 2.0 will still hold an important place in Java Web stacks.

“I think the usage model posed by GWT is very intriguing, but what I've seen by talking to customers is that they really can't afford to stay inside that intriguing but constrained toolkit Google provides. Right now, they have their RMI interaction where components can talk to POJOs [Plain Old Java Objects] on the server,” said Burns.

But when it comes to accessing the forthcoming Web Beans, or the Java persistence API, JSF will remain a stable and mature solution, he added. In fact, the forthcoming Web Beans specification, JSR 299, is closely tied to the JSF 2.0 specification. Burns and Kitain said that this will allow JSF to interact more easily with the Java Persistence API and other heavyweight Java processes and tools.

Perhaps the most significant change to JSF 2.0, however, is a piece that Burns and Kitain have already begun coding. “For the first time in Java EE, we'll have a concept of a software development life cycle. The developer can say, ‘Now I'm in debug mode, or development mode,' and the runtime will know that 'since the developer is telling me this, I can give advanced error messages and advanced stack traces.' If you set that flag to production mode, you'll see friendlier error messages,” said Burns.

JSF 2.0 should arrive as an early draft specification in the first part of next year. Beyond that, Kitain and Burns could not predict more specific timelines. JSR 314 is part of the larger effort toward Java EE 6, however, and it's hoped that the completed specification and reference implementation will arrive alongside that specification.


Share this link: http://www.sdtimes.com/link/31435
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading