9.1 Appropriate Usage of JSP in an Enterprise Application

I l @ ve RuBoard

A JSP page is converted to a servlet before it's called on to serve requests . This means that a JSP page can do anything a servlet can do, but it doesn't mean JSP is appropriate for all tasks .

9.1.1 Favor Using JSP as the View Only

For a very simple application, using JSP for all parts of the application might be acceptable, but in most cases, I recommend following the Model-View-Controller (MVC) design pattern and using JSP only for the View. If you use JSP for all parts , you typically encounter these types of problems:

• Common features need to be implemented in many places. If logic for access control, logging, and statistics collection is duplicated in most JSP pages, changes in these areas require changes to many parts of the application.

• Business logic is harder to develop, debug, reuse, and maintain if it's implemented as JSP action elements or Java code scriptlets in JSP pages. While some integrated development environments ( IDEs ) support a rich environment for JSP development and debugging, nonvisual aspects of the application are better done as regular Java classes, in which the full power of the language's object-oriented features and standard program development tools can be leveraged.

• Changes to the database schema or data source type require changes in all JSP pages that access the data source directly.

• The application page flow is hard to visualize and manage because it's spread throughout the application pages.

Combining JSP with other J2EE technologies solves all these problems. The frameworks described in Chapter 3, such as Apache Struts, ^[1] can help you develop easy-to-manage web applications. Struts provides a generic Controller server, dispatching requests to simple classes ( Action classes) that handle the individual request types and pick the JSP page for rendering the response based on the outcome (and possibly other runtime conditions, such as client type or the user 's language preferences). Other component types defined in the servlet specification are suitable for other common tasks ”for example, an application lifecycle listener is perfect for initialization of application resources, and a servlet filter can handle application-controlled access control. To isolate the application from data source and schema changes, all access to persistence data should be performed by separate data access objects.

^[1] Struts is available at http://jakarta.apache.org/struts/.

Figure 9-1 outlines the main parts of a product catalog application based on Struts, in which the MVC roles are allocated to these J2EE component types.

Figure 9-1. An application using JSP combined with other J2EE technologies

When the application starts, the ResourceInitListener creates a single instance of the CatalogDAO class and makes it available to other parts of the application as a servlet context attribute. The CatalogDAO is a data access object, encapsulating all details about how to access product information stored in a database. If the database schema is changed, or if the SQL statements need to be changed when switching to a database from a different vendor, this is the only class that needs to be changed. The data access object contains methods that return a ProductBean representing a specific product or a list of ProductBean instances that match a search criterion.

All requests are sent to the Struts Controller servlet, which uses a part of the URL to identify the Action subclass responsible for processing the request. Each Action subclass is a simple class with a single method that performs all processing and returns the name of the View that should be used to render the response. In Figure 9-1, the ListAction class is invoked to handle a request for a list of products. It uses a search criterion (e.g., a product category) received with the request to get a list of matching ProductBean instances from the CatalogDAO , saves the list as a request attribute, and returns a View name to the Controller. The Controller maps the returned View name to the URL for the corresponding JSP page ”the list.jsp page in this example ”and forwards the request to the page. The JSP page gets the list of products saved as a request attribute by the ListAction class and renders an HTML list with an entry for each product. Each product entry is rendered as a link with a URL that the Controller recognizes as a request to invoke DetailsAction . This action gets a specific ProductBean from the CatalogDAO , adds a reference to it in the request, and tells the Controller to render the response using the details.jsp page. While this description is brief, it hopefully gives you an idea of how the work is distributed between the different components and how they match the Model, View, and Controller roles.

This separation of tasks makes it possible to modify the business logic without touching the user interface, and vice versa. It also means that logging and other central functions can be managed in just one place, and it minimizes the amount of logic needed in the JSP pages. The remaining logic, such as looping through the product list and rendering the product information as HTML elements, can easily be done using the JSP Standard Tag Library (JSTL) actions. JSTL actions or custom actions should be used in favor of Java code scriptlets because the scriptlet syntax is very error-prone and is likely to intimidate nonprogrammers who eventually will change the application user interface layout and style.

9.1.2 Consider Using Separate JSP Pages for Each Role

For a very simple application (for example, up to five web pages and business logic consisting of just reading and writing to one or two database tables), splitting the functionality between different component types can be overkill. If you decide to use only JSP for such an application, I still recommend staying close to the MVC model; use separate JSP pages for the user interface (View) and the nonvisual parts (Controller and Model), as shown in Figure 9-2.

Figure 9-2. Application using separate JSP pages for the View and Controller/Model parts

This makes it easier to maintain the application for the same reasons described earlier, and also makes it easier to replace the business logic implementation with servlets and other Java components later, if needed.

9.1.3 Avoid Using Scripting Elements

Whether you use JSP pages for only the View portion of the application or for other roles as well, avoiding scripting elements (i.e., raw Java code in the pages) is always a good idea. Using scripting elements exposes you to, at least, the following problems:

• Syntax errors are very easy to make and extremely hard to locate because the scripting element code is interleaved with the code generated by the container.

• Scripting code can be reused only through copy/paste.

• To a nonprogrammer charged with maintaining the look-and-feel aspects of the pages, scripting code is very distracting and easy to corrupt by mistake. Some web page authoring tools used by this group of people also remove or corrupt scripting elements.

Before the introduction of custom tag libraries in JSP 1.1, scripting elements were your only choice. Even in the latest JSP version, scripting elements are still supported (because Java specifications go to great lengths to be backward-compatible ). But with the introduction of custom tag libraries, and especially the libraries defined by the JSTL specification, there's really no good reason to use scripting elements anymore.

I l @ ve RuBoard