February 26, 2021
Hot Topics:

The Many Faces of JavaServer Faces (JSF)

  • By Michael Nash
  • Send Email »
  • More Articles »

No doubt the name at least is familiar: JavaServer Faces has been talked about a lot, and much anticipated, with good reason. For years there have been an ever-expanding choice of ways to take your web application's output and get it on a page (or on some other kind of display). The Servlet API did a lot to enable the first Java web applications - having created web applications for Java before Servlets, I can attest to how much it helped! The first web applications with Servlets cranked out HTML directly - pretty much everyone now agrees this was a bad plan, and hard to maintain to boot. Next came toolkits such as Apache's Element Construction Set that generated the HTML for you. A step in the right direction, but not far enough for most. Then came JSP: A hybrid, in some ways, between an HTML page and a Servlet. JSP was a significant step forward from Servlet-generated HTML - If you use it right (and that's a critical if), you can enforce a pretty clean separation of view and application logic. Better still, JSP's, particularly once tag libraries came along, were simple enough that non-programmers could help with the page layout process, particularly for HTML formatting.

Other UI technologies went in different directions, though: Apache's Velocity, similar and to some degree a successor to the popular WebMacro project, applied a simple but extensible template language to generating the UI portion of an application, reading JavaBean properties from the Servlet context (where the application logic put it). Tea, Maverick, WebWork2, Scope, Echo, FreeMarker, Barracuda, Cocoon - all took different, and in some cases radically different, approaches to getting the data from the application logic to the page.

Sometimes, as in the case of Barracuda, Cocoon, and several others, XML was involved, and potentially XSL transformations. Many of these frameworks also delved into the application logic side of the equation, proving much more than a UI system. Struts is perhaps the most widely known example, taking the JSP approach to a new level with a powerful custom tag library, and popularizing the concept and advantages of Model/View/Controller that Smalltalk old-timers were so familiar with. Over time, many common elements began to emerge between such frameworks, and it became clearer what the best practices were for UI technology in a web environment, what worked and what didn't. Developers realized that web applications that used HTML/HTTP as the basis of their UI were quite different animals from desktop or "thick" client applications using Swing or other such toolkits. The user, however, still wanted a rich and responsive UI experience. There was still a wide gap in the way the various frameworks produced the display from the data produced from the application logic, and techniques and UI elements created for one technology were not portable to the next. You couldn't take a custom JSP tag from Struts and use it in an application build with Scope, for example. You couldn't take UI components for Echo and easily apply them to an application built with Cocoon. This meant that anyone attempting to build tools to make it easier for page/UI designers to do their job had to back one horse, or write many different tools, neither of which was a very attractive option. As a result, Java and J2EE lacked the rich graphical tools to help build applications by comparison to an up-and-coming rival, .NET. While the hard-boiled "vi" crowd didn't see this as a problem, it did limit the adoption of Java and of many of these different frameworks in many organizations, where experienced developer resources were not available for creating Luis. Either the UI got short shrift - the results of which we can see on the web today in the many horrifying anti-examples of usability out there - or the development project went wildly over budget re-inventing the wheel, because there was no standard wheel to do UI development. The other choice was to commit to a single UI framework approach, and abandon any possibility of portability later on.

JSF should change all that - one of it's goals is to bring a single common standard that tool-creators can use to build their tools against, while still allowing many different options for rendering the finished UI. One JSF-based design tool should be able to be used on many different JSF implementations, and components should be portable from one implementation to the next, so that neat UI gizmo you built for one application really can be re-used on another.

Sounds great - but where's the beef? How is JSF going to accomplish these admittedly lofty goals? Let's look at JSF from several different perspectives, and talk about about where the rubber meets the road - how you'll be able to apply JSF from a practical perspective on your development projects, no matter what UI technology you're currently backing.

It's important to realize that JSF is not tied inextricably to JSP, even though the reference implementation demonstrates JSF with JSP. JSF defines non-visual UI components, which sounds like a contradiction in terms - the idea, however, is to separate the definition of a UI component from it's presentation. Much like dividing up UI and application logic, but at a finer level. Now we're talking about dividing up the UI into a non-visual representation and a rendering - a translation of that non-visual representation into an actual display. That rendering can be done in any number of ways, as we will see.

Page 1 of 2

This article was originally published on January 5, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date