Chapter 4. JavaServer Pages

In Chapter 3, we looked at Java servlets, J2EE's primary mechanism for communicating with web browsers. Servlets are a great technology, but they don't solve every problem faced by web developers, and they introduce a few issues of their own. One major problem is that developing complex HTML-based user interfaces with servlets is time-consuming. Embedding strings of println( ) statements is tedious and error-prone and requires that pages be assembled by a fully qualified programmer who, just perhaps, should be off doing other things. Configuration is also a problem, although it has been simplified a great deal since the original Servlet API. Adding a new servlet to a web application involves editing the deployment XML file and typically reloading the application or restarting the server.^[*] Changes to a servlet create the same issues, turning rapid prototyping into regular prototyping.

^[*] Dynamic class reloading and change detection solve some of these problems, but not for all servers and not always reliably.

On the design side, servlets can also blend application logic with presentation logic, undoing one of the primary benefits of the client/server architectures that they often replace. In a canonical J2EE environment, where business logic is abstracted into Enterprise JavaBeans or other middleware, this is not much of a concern. But in real life, full J2EE systems aren't always appropriate. Many applications don't need the full weight of an application server, and often developers lack the interest or time to create a full J2EE implementation. And even within a J2EE application, there are substantial benefits to separating flow control (accomplished by servlets) from actual pages.

One obvious approach is to use static HTML content for most pages, reserving servlets for forms processing with a redirect or forward to another HTML page upon completion. Such an approach breaks down fairly quickly, as most pages in a web application have at least some dynamic element. A better solution, however, is to embed dynamic elements directly into the static content. This is the reverse of the approach servlets use, where static content is embedded within the dynamic framework.^[*] Static web pages with a few dynamic content extensions can be edited using any HTML authoring tool and previewed live in the browser, either with or without the dynamic elements (obviously, the efficacy of this last technique depends on the complexity of the page).

^[*] Since the dawn of civilization, humankind has sought to embed code within content. Great, if virtual, wars have been fought over the advisability of actually doing so. At this point, very few people consider it wise to embed all of their presentation HTML directly within a servlet, but there is wide divergence of opinion on how much code is appropriate for a JSP . In truth, the answer depends on your application. It's safe to say that the larger or longer lived you expect your application to be, the more likely you will benefit from a clean separation of code and content.

There have been a few different approaches to creating dynamic web pages without a full servlet. Generally, these involve inserting either custom tags or control statements within HTML document templates and then running the documents through a server-side processor that replaces tags and directives with dynamically generated content. The resulting pure HTML is delivered to the client. This type of templating system is shown in Figure 4-1. In a servlet environment, the template processor will be implemented as one or more servlets. Examples of templating engines include WebMacro (http://www.webmacro.org) and Velocity (http://jakarta.apache.org/velocity).

Figure 4-1. Generic templating engines

Sun's templating solution is called JavaServer Pages, or JSP, which is currently at Revision 2.0. JSP is a highly integrated dynamic content system that is built on top of the Java Servlet API. In fact, JSPs are compiled into Java servlets before being executed by the web server. This allows JSP developers to obtain all the advantages of Java servlets (efficient lifecycles, integration with Java middleware, and so on) without spending hours integrating HTML into actual Java code. JSP also allows page developers to access properties of Java beans without writing code. Finally, custom JSP tags can be created by developers for use by page designers, removing Java code from the JSPs entirely.

Along with the Servlet API, the JSP API is part of the J2EE specification. J2EE 1.4 incorporates JSP 2.0, which was released in 2003. Earlier versions of J2EE supported JSP 1.2. We will indicate changes when possible, but this chapter focuses on the 2.0 version of the standard.

JSP is also closely integrated with the JavaServer Faces and Struts application frameworks, which are described in Chapters 5 and 19, respectively. In both systems, JSPs provide the user interface, collaborating with extensions provided by the application framework. Other parts of this book that you may find especially relevant include Chapter 2, where we provide details on assembling and deploying web components, and Chapter 21, where we discuss code annotation systems that can be used to automatically generate deployment descriptors and other artifacts for web applications.

In this chapter, we are going to look at JSP from a Java programmer's perspective as opposed to that of a web site designer. Of course, one of the great things about JSPs, and other templating technologies, is that you don't have to be a programmer to use them. However, for a more thorough introduction to JSP, as well as some substantial additional detail for experienced developers, we suggest JavaServer Pages by Hans Bergsten (O'Reilly).