[ Team LiB ] Previous Section Next Section

Choosing Between JavaServer Pages and Servlets

Although you've just barely scratched the surface of JSPs and Servlets, now is a good time to talk about when to use servlets, when to use JSPs, and when to use both. To make such decisions, you need to weigh the advantages and disadvantages of each. Remember, too, that because JSPs are translated into servlets, they can't be all that different when you get right down to it.

The Advantages and Disadvantages of JSPs

The biggest strength of a JSP is that it looks like HTML (or XML or whatever kind of content you are generating). You can give a JSP to someone who is familiar with HTML and expect that person to be able to make changes fairly quickly. It is also quite obvious what the HTML will look like when it is sent to the browser. It is not always so obvious when Java code generates the HTML.

JSPs were developed to better separate content from code. Such separation makes it easier for Web page authors and software developers to do their jobs somewhat independently. The division better leverages the skills required for either job and makes it easier to develop reusable components. With JSP 2.0, significant improvements have been made that make it possible for authors and developers to be even more effective. Later in the book, you'll learn more about these.

A much more subtle advantage of JSPs, one that you may not have really encountered yet, is that when the JSP is turned into a servlet, that servlet is automatically loaded into the servlet container. When the JSP changes, its corresponding servlet is automatically regenerated and reloaded. When you are doing rapid development, it's great to be able to make quick changes and see them without having to restart the server. If you make a lot of changes to a lot of files, you don't have to worry about reloading all the changed files; the JSP container picks them up automatically.

Because JSPs eventually become servlets, it's difficult to point to any technical disadvantages of a JSP that aren't also present in servlets. The greatest disadvantage I've seen in practice is related to the greatest strength of JSPs: the capability to mix in Java code with HTML. If you aren't careful in organizing your code, you can end up with an ugly mess: huge JSP files with HTML interspersed between huge blocks of Java code. Things only get worse if you do a lot of JavaScript in the page, too. It can be terribly confusing to look at a page and not know whether you are looking at server-side Java code or client-side JavaScript. Fortunately, you will learn ways around this in the next few hours.

The Advantages and Disadvantages of Servlets

For the most part, the advantages of servlets are the disadvantages of JSP and vice versa. Because servlets are Java classes, you don't end up with a huge mess of Java, HTML, and JavaScript. Everything in your servlet is Java. Of course, when the servlet is generating HTML or XML, you might find that you still have a huge mess in the form of many out.print and out.println statements.

You were probably impressed by the differences in deployment. Most of the time, servlets must be packaged to be deployed. You needed to specify a special URL or at least a URL pattern (such as /servlet/) for executing a servlet, when for a JSP all you need to have is a filename that ends with .jsp. This makes your site configuration a little more tedious to maintain. However, as you develop Web applications that include many elements, you will find that packaging is actually a great thing. Finally, servlets are not always automatically reloaded by the servlet container, although most popular servlet containers do reload them automatically.

It probably sounds as if I'm biased in favor of JSPs, and I can't really dispute that—at least for early development. Because a JSP eventually becomes a servlet, you have the entire servlet API available to you from within the JSP. When it comes to deploying a full production system, however, it is often easier to manage servlets. Most of the configuration options in the JSP/Servlet deployment file (that is, web.xml) are oriented to servlets.

An interesting combination of servlets and JSPs that builds upon the strengths of each has become popular with developers. When the initial request comes in, it is handled by a servlet. The servlet performs any business logic, such as fetching data from the database, doing computations, or pulling data in from other sources. When it's time to send a response back to the browser, the servlet calls a JSP to render the output. This uses the strength of each of these technologies: The servlet is a simple Java class, whereas the JSP is a template geared toward generating output. You will learn more about this technique in Hour 20, "Building Web Applications with JavaServer Pages and Servlets" and in Hour 21, "Using Struts and JavaServer Faces."

When Should I Use a Servlet for Output?


One rule of thumb that many Web developers use is that if you generate binary data like JPEG or audio files, use a servlet; if you generate text, use a JSP. Furthermore, use a JSP if you want to edit generated text directly. If you generate the text completely automatically (running an external command and displaying the output, for example), use a servlet.

If you take a little extra time, you can create a JSP that doesn't contain any Java code at all. It might seem a little strange to make a JSP with no Java code, but throughout the rest of this book, you will learn about built-in JSP tags that enable you to access Java objects as well as a tag extension mechanism that enables you to create new JSP tags. In addition, for those times when you do require some control within a JSP, JSP 2.0 adds the Expression Language as a higher-level programming feature. Using these features, you can easily eliminate embedded Java code, which some would argue is the best way to use JSPs.

It probably sounds a little too simplistic, but you should use the technology that best fits your requirements. If you have a lot of static HTML, XML, WML, or another textual markup language, use a JSP. If you are sending back binary data, such as an image or an audio file, a servlet is probably a better bet (not from a technical standpoint, just an aesthetic one).

    [ Team LiB ] Previous Section Next Section