JavaServer Faces in Action: Introducing JavaServer Faces

A popular term in the pre-Web days was Rapid Application Development (RAD). The main goal of RAD was to enable you to build powerful applications with a set of reusable components. If you’ve ever used tools like Visual Basic, PowerBuilder, or Delphi, you know that they were a major leap forward in application development productivity. For the first time, it was easy to develop complex user interfaces (UIs) and integrate them with data sources.

You could drag application widgets—UI controls and other components— from a palette and drop them into your application. Each of these components had properties that affected their behavior. (For example, font is a common property for any control that displays text; a data grid might have a dataSource property to represent a data store.) These components generated a set of events, and event handlers defined the interaction between the UI and the rest of the application. You had access to all of this good stuff directly from within the integrated development environment (IDE), and you could easily switch between design and code-centric views of the world.

RAD tools were great for developing full-fledged applications, but they were also quite useful for rapid prototyping because they could quickly create a UI with little or no code. In addition, the low barrier to entry allowed both experienced programmers and newbies to get immediate results.

The underlying component architectures were extensible enough to spawn an industry of third-party component developers like Infragistics and Developer Express. Of course, the RAD philosophy never went away—it just got replaced by other hip buzzwords. It’s alive and well in some Java IDEs and other development environments like Borland Delphi and C++Builder. Those environments, however, stop short of using RAD concepts for web projects. The adoption of RAD in the web development world has been remarkably slow.

This sluggishness is due in part to the complexity of creating such a simple, cohesive view of application development in a world that isn’t simple or cohesive. Web applications are complex if you compare them to standard desktop applications. You’ve got a ton of different resources to manage—pages, configuration files, graphics, and code. Your users may be using different types of browsers running on different operating systems. And you have to deal with HTTP, a protocol that is ill suited for building complex applications.

The software industry has become good at masking complexity, so it’s no surprise that many RAD web solutions have popped up over the last few years. These solutions bring the power of visual, component-oriented development to the complex world of web development. The granddaddy is Apple’s WebObjects, 2 and Microsoft has brought the concept to the mainstream with Visual Studio. NET and ASP.NET Web Forms. In the Java world, many frameworks have emerged, several of them open source. Some have tool support, and some don’t. However, the lack of a standard Java RAD web framework is a missing piece of the Java solution puzzle—one that Microsoft’s. NET Framework has covered from day one. JavaServer Faces was developed specifically to fill in that hole.

1 The Java Community Process (JCP) is the public process used to extend Java with new application programming interfaces (APIs) and other platform enhancements. New proposals are called Java Specification Requests (JSRs).

1.1.1 So, what is JavaServer Faces?

In terms of the four layers of a RAD tool, JavaServer Faces defines three of them: a component architecture, a standard set of UI widgets, and an application infrastructure. JSF’s component architecture defines a common way to build UI widgets. This architecture enables standard JSF UI widgets (buttons, hyperlinks, checkboxes, text fields, and so on), but also sets the stage for third-party components. Components are event oriented, so JSF allows you to process client-generated events (for instance, changing the value of a text box or clicking on a button).

Because web-based applications, unlike their desktop cousins, must often appease multiple clients (such as desktop browsers, cell phones, and PDAs), JSF

Figure 1.1 IBM’s WebSphere Application Developer (WSAD) has been expanded to support JSF applications in addition to the seemingly endless amount of other technologies it supports. You can visually build JSF applications, and mix-and-match other JSP tag libraries using WSAD’s familiar Eclipse-based environment.

has a powerful architecture for displaying components in different ways. It also has extensible facilities for validating input (the length of a field, for example) and converting objects to and from strings for display.

Faces can also automatically keep your UI components in synch with Java objects that collect user input values and respond to events, which are called backing beans. In addition, it has a powerful navigation system and full support for multiple languages. These features make up JSF’s application infrastructure— basic building blocks necessary for any new system.

JavaServer Faces defines the underpinnings for tool support, but the implementation of specific tools is left to vendors, as is the custom with Java. You have

a choice of tools from industry leaders that allow you to visually lay out a web UI in a way that’s quite familiar to users of RAD development tools such as Visual Studio. NET. (Figures 1.1, 1.2, and 1.3 show what Faces development looks like in IDEs from IBM, Oracle, and Sun, respectively.) Or, if you prefer, you can develop Faces applications without design tools.

Just in case all of this sounds like magic, we should point out a key difference between JavaServer Faces and desktop UI frameworks like Swing or the Standard

Widget Toolkit (SWT): JSF runs on the server. As such, a Faces application will run in a standard Java web container like Apache Tomcat [ASF, Tomcat], Oracle Application Server [Oracle, AS], or IBM WebSphere Application Server [IBM, WAS], and display HTML or some other markup to the client.