Is Java Server Faces a Bona Fide Panacea for the Web UI?
You will learn about JSF technology (JSR 252), its structure, configuration, pros and, cons. I will talk about the history that led to JSF. I will also discuss industry support both on the vendor and the IDE sides. As of this writing, the JSF is up to version 1.1_01, but the spec for 1.2 is compete and reference implementation should be available shortly. Also, understand that this technology is rather vast and I will cover only the general aspects of it in this article.
The Events Leading to the JSF
In the beginning, there were Plain Old Java Objects (POJOs) and Java Applets. Business programs were supposed to run in the browser. However, IT managers soon realized that most did not have broadband connections and downloading Java Virtual Machine and Applets was time consuming. Around that period (before Just-In-Time [JIT] compiler technologies were introduced), managers also noticed that applications and applets run somehow slower then their cousins written in C/C++, VB, or other natively compiled languages. In addition, users noticed that Applets had restrictions and could not do many things that applications could.
Sun Microsystems stepped up with the Servlet technology and Java moved from running on the client's browsers to running on the servers. Sun also introduced the JIT compilation process, optimized their JVM, and Java applications started to run faster.
And all was good for a while.
But soon, IT managers realized that Servlets disgorge HTML to the clients and HTML pages need to look presentable to provide a better user experience to drive up the revenues. But, programmers who were willing to write all HTML by hand, inside Java code, literally as output statements that would perform dynamic functions and look appealing were very hard to find. Therefore, again Sun stepped up with the Java Server Pages (JSP) technology.
Designers could create HTML pages that look great and Java programmers could take them, spruce them up with tiny Java tags and snippets, and the Java server container would parse and convert them into the HTML to be disgorged to the clients.
And all was good for a while.
The "perpetual" solution, or at least part of it, is supposed to be the Java Server Faces (JSF) technology; A sort of RAD (rapid application development) concept from the Visual Basic era. However, I will leave it up to the readers to make the conclusion.
Rapid Application Development (RAD)
The Java Standard Tag Library (JSTL) introduced a couple of years back created a standard way to replace Java snippets with tags. The tag can do almost any business logic and can be re-used throughout many applications. JSTL tags did not address any visual aspects of the applications, but helped to eliminate some of the maintenance problems associated with editing business logic on the pages.
Rapid Application Development (RAD) is sort of a "holy grail" of the GUI Web applications. When working with Java Swing, Visual Basic, or PowerBuilder programs, developers can drag-and-drop GUI components, such as buttons or text fields, and create full-featured interactive applications. With the HTML as the end result of some server operation, the presentation is not linked to the Java backend and RAD is not truly possible.
The HTML editor can be used to create forms, but it cannot add events to buttons or link controls to the backing beans; therefore, a lot of work still needs to be done manually. To accomplish RAD with tags, a new technology needed to be created.
Realizing this need, Sun developed the JSF specification. The JSF technology introduced tags for all HTML elements—such as buttons, tables, and checkboxes—and corresponding Java Objects to hold the state or model of the view. An IDE supporting JSF can allow developers to drag-and-drop tags and create the forms so instead of writing HTML:
<input type="text" id="inputText"/>
One would write the JSF tag:
JSF added the ability to attach converters, validation, and even actions and events to the corresponding Java objects on the server—all expressed as tags, potentially bringing a true RAD feel and Swing development style to Web development.
For example, Borland JBuilder supports JSF tags, but cannot auto preview them, so the Java developers (who now became HTML designers) need to deploy the app on the server and recompile/refresh JSPs page every time they make a visual change. Oracle JDeveloper 10 and Exadel Studio pro do have design/layout and preview capability inside of their IDEs and on-the-fly editing of the dragged-and-dropped JSF components, but their HTML editors are not as mature as Dreamweaver.
Almost all of IDEs that support JSF also offer visual editors for the navigation flow management that eliminates the need to tinker with the XML by hand (see the next section).
JSF as a MVC Framework
The proliferation of Web-based applications, concurrent with the migration of Java from the client to the server and the evolution of the Servlets, JSP, and other Web-based technologies, created numerous development frameworks along the way. I have covered some of the most popular ones in my previous articles.
By design, JSF constitutes a much broader technology then just another MVC framework. One of the aspects of the JSF is that it controls Web application flow. The page navigation is mapped out in the configuration XML file and the main controller Servlet coordinates the flow (among other things). JSF can be considered a full MVC framework because the presentation layer (most commonly a JSP page) is separated from the Java beans or "managed beans" as the JSF identifies them. Depending on the render toolkit used, the view shown to the client can be HTML, WML, SGML, and so on.
Mostly, JSF is marketed as a component framework for the presentation layer, but its MVC characteristics overlap with Struts, Spring, and other popular frameworks. Even though they can co-exist in the same application, architects can design enterprise-level Web sites with only JSF. In fact, JSF navigation rules are very easy to describe, and depending on the tool used, most of the flow and underlining XML configuration can be created visually in very little time. Even describing the managed beans, their properties, validators, and converters in the XML config file is a trivial task with the right tool (such as the free James Holmes' Faces Console or Exadel Studio pro).
Here is a screen shot of the visual navigation rules layout in Oracle JDeveloper 10g:
Here is a similar shot of the visual navigation rule layout in Borland JBuilder 2006: