3.3 JSP Processing

[ Team LiB ]

3.3 JSP Processing Just as a web server needs a servlet container to provide an interface to servlets, the server needs a JSP container to process JSP pages. The JSP container is responsible for intercepting requests for JSP pages. To process all JSP elements in the page, the container first turns the JSP page into a servlet (known as the JSP page implementation class). The conversion is pretty straightforward; all template text is converted to println( ) statements similar to the ones in the handcoded servlet shown in Example 3-1, and all JSP elements are converted to Java code that implements the corresponding dynamic behavior. The container then compiles the servlet class. Converting the JSP page to a servlet and compiling the servlet form the translation phase. The JSP container initiates the translation phase for a page automatically when it receives the first request for the page. Since the translation phase takes a bit of time, the first user to request a JSP page notices a slight delay. The translation phase can also be initiated explicitly; this is referred to as precompilation of a JSP page. Precompiling a JSP page is a way to avoid hitting the first user with this delay. It is discussed in more detail in Chapter 17. The JSP container is also responsible for invoking the JSP page implementation class (the generated servlet) to process each request and generate the response. This is called the request processing phase. The two phases are illustrated in Figure 3-3. Figure 3-3. JSP page translation and processing phases As long as the JSP page remains unchanged, any subsequent request goes straight to the request processing phase (i.e., the container simply executes the class file). When the JSP page is modified, it goes through the translation phase again before entering the request processing phase. The JSP container is often implemented as a servlet configured to handle all requests for JSP pages. In fact, these two containers�a servlet container and a JSP container�are often combined in one package under the name web container. So in a way, a JSP page is really just another way to write a servlet without having to be a Java programming wiz. Except for the translation phase, a JSP page is handled exactly like a regular servlet; it's loaded once and called repeatedly, until the server is shut down. By virtue of being an automatically generated servlet, a JSP page inherits all the advantages of a servlet described in Chapter 2: platform and vendor independence, integration, efficiency, scalability, robustness, and security. 3.3.1 JSP Elements There are three types of JSP elements you can use: directive, action, and scripting. A new construct added in JSP 2.0 is an Expression Language (EL) expression; let's call this a forth element type, even though it's a bit different than the other three. 3.3.1.1 Directive elements The directive elements, shown in Table 3-1, specify information about the page itself that remains the same between requests�for example, if session tracking is required or not, buffering requirements, and the name of a page that should be used to report errors, if any. Table 3-1. Directive elements Element Description <%@ page ... %> Defines page-dependent attributes, such as session tracking, error page, and buffering requirements <%@ include ... %> Includes a file during the translation phase <%@ taglib ... %> Declares a tag library, containing custom actions, that is used in the page 3.3.1.2 Standard action elements Action elements typically perform some action based on information that is required at the exact time the JSP page is requested by a browser. An action can, for instance, access parameters sent with the request to do a database lookup. It can also dynamically generate HTML, such as a table filled with information retrieved from an external system. The JSP specification defines a few standard action elements, most of them listed in Table 3-2.[1] [1] There are a few more action elements, used in combination with these standard actions or custom actions or in very special cases. They are introduced as they are used in the examples later in this book. Table 3-2. Standard action elements Action element Description <jsp:useBean> Makes a JavaBeans component available in a page <jsp:getProperty> Gets a property value from a JavaBeans component and adds it to the response <jsp:setProperty> Sets a JavaBeans component property value <jsp:include> Includes the response from a servlet or JSP page during the request processing phase <jsp:forward> Forwards the processing of a request to a servlet or JSP page <jsp:param> Adds a parameter value to a request handed off to another servlet or JSP page using <jsp:include> or <jsp:forward> <jsp:plugin> Generates HTML that contains the appropriate browser-dependent elements (OBJECT or EMBED) needed to execute an applet with the Java Plugin software 3.3.1.3 Custom action elements and the JSP Standard Tag Library In addition to the standard actions, the JSP specification defines how to develop custom actions to extend the JSP language, either as Java classes or as text files with JSP elements. The JSP Standard Tag Library (JSTL) is such an extension, with the special status of being defined by a formal specification from Sun and typically bundled with the JSP container. JSTL contains action elements for the type of processing needed in most JSP applications, such as conditional processing, database access, internationalization, and more. This book covers all the JSTL actions in detail. If JSTL isn't enough, your team (or a third party) can use these extension mechanisms to develop additional custom actions, maybe to access application-specific resources or simplify application-specific processing. The examples in this book use a few custom actions in addition to the JSTL actions, and one chapter in Part II and three chapters in Part III are dedicated to custom action development. 3.3.1.4 Scripting elements Scripting elements, shown in Table 3-3, allow you to add small pieces of code (typically Java code) in a JSP page, such as an if statement to generate different HTML depending on a certain condition. Like actions, they are also executed when the page is requested. You should use scripting elements with extreme care: if you embed too much code in your JSP pages, you will end up with the same kind of maintenance problems as with servlets embedding HTML. Table 3-3. Scripting elements Element Description <% ... %> Scriptlet, used to embed scripting code <%= ... %> Expression, used to embed scripting code expressions when the result shall be added to the response; also used as request-time action attribute values <%! ... %> Declaration, used to declare instance variables and methods in the JSP page implementation class 3.3.1.5 Expression Language expressions A new feature in JSP 2.0 is the Expression Language (EL), originally developed as part of the JSTL specification. The EL is a simple language for accessing request data and data made available through application classes. EL expressions can be used directly in template text or to assign values to action element attributes. Its syntax is similar to JavaScript, but much more forgiving; it's constrained in terms of functionality, since it's not intended to be a full-fledged programming language. Rather, it is a glue for tying together action elements and other application components. There are way too many elements of the EL to list here, but they are all introduced in Chapter 5 and described in detail when used in examples. 3.3.1.6 JavaBeans components JSP elements, such as action and scripting elements, are often used to work with JavaBeans components. Put succinctly, a JavaBeans component is a Java class that complies with certain coding conventions. JavaBeans components are typically used as containers for information that describes application entities, such as a customer or an order.

[ Team LiB ]