Comparing JSP with Servlets

As you have seen JSPs have several advantages over servlets. They

• Are quicker to write and develop

• Focus on the page layout and delegate Java logic to supporting JavaBeans and custom tags (as will be discussed on Day 14)

• Differentiate the Web page presentation (HTML) from the underlying logic (Java)

• Can be written by non-Java–aware developers provided suitable supporting beans and tag libraries are available

• Support a standard error reporting mechanism using the error page directive

However, JSPs do have some downsides:

• Error identification and correction is complicated by the translate and compile lifecycle.

• Large volumes of embedded Java scriptlets can reduce the maintainability of the page.

In general, you should use JSPs with JavaBeans and custom tag libraries whenever possible. The speed of development and the quick turnaround on look and feel or simple functional changes that is possible with JSPs is a major advantage in modern Web-based applications.

Consider using servlets only when the Java code is complex or needs to be “hand crafted” for efficiency.

One common approach for supporting complex Java requirements is to use a servlet for the Java code and a supporting JSP for the presentation. The Java servlet accesses the information and stores it in the session context. The servlet then forwards the HTTP request to the JSP, which retrieves the data from the session context and presents it back to the client as HTML. This approach still maintains the differentiation between presentation and logic.

An additional advantage of this servlet/JSP approach is that the servlet can use one of several JSPs to present the data according to the type of client making the request. You can define one JSP for HTML clients (PCs) and another for WML clients (mobile phones). In the future, you can add additional clients for, say, XML clients or a presentation language than has not yet been defined. All of these different presentation requirements can be supported by a single servlet. Any future changes to the underlying business rules are only made once in the logic of the servlet, with any necessary changes in the presentation being made in the appropriate JSPs.