< Zurück | Inhalt | Weiter >

Chapter 19


Servlets Turned Inside Out


In our last chapter, the BudgetPro servlet example spent a lot of code generating the HTML output for the servlet to send back to the browser. If you want to change the HTML for any page (for example, add a background color), you would have to modify the Java code (obviously)—but you’re not really wanting to modify the logic of the servlet, you only want to tweak its output. The HTML that a servlet generates can be scattered among output statements, string concatenations, classes, and method calls. Servlets, we might say, bury the HTML deep inside the code. We’re now going to take a look at JavaServer Pages (JSP) which do the opposite—they expose the HTML and hide the code down inside.

This technique has been given the fancy description, document-centric server-side programs. They are “document-centric” because the HTML code is so visible—JSP content looks like (and is) HTML with some additions. They are “server-side” because all the work is done on the server and all the additions and special features of JSP are boiled down to a simple stream of HTML by the time it gets to the browser.




• Theory of operation: how JSP can be thought of as servlets “inside out.”

• Three simple JSP directives: scriptlet, declaration, expression.

• Servlet variables made available: request, response, out, session.

• Server-side includes.

• A tiny bit about tags.


• A look at our BudgetPro using JSP.

• The correct spelling of JavaServer Pages.


Take a look at the AccountView.java class in the BudgetPro servlet example.

It consists almost entirely of


method calls which build up a string of HTML. Instead, this could have been calls to do the output right then and there:


Either way, if we want to modify the HTML, we have to modify the Java code. While that’s not difficult, it can be error-prone. It would be nice to not have the Java syntax in the way when we want to modify the HTML. (That’s especially true when you want to put quotation marks in your HTML:

out.println("<input name=\"name\" size=\"20\">");

It’s not that it can’t be done; the \" just gets hard to read and hard to get right the first time.)

One way to externalize all the HTML is to put it into a file. Then our Java application could read the file at runtime and send its contents to the browser. Not bad, but what about the dynamic parts? Remember how we generated the table from the for loop in AccountView.java:

19.2 Servlets Turned Inside Out: JSP 425


for (Iterator actit = acct.getAllSubs(); actit.hasNext(); ) { Account suba = (Account) actit.next();


sb.append("<td><a href=\"BudgetPro?name="+suba.getName()); sb.append("&func=cd\">");

sb.append(suba.getName()); sb.append("</a></td>"); sb.append("<td>albing</td>"); sb.append("<td>"); sb.append(suba.getTotal().toString()); sb.append("</td>"); sb.append("</tr>\n");

} // next acct

That would be hard to do with file-based HTML.

Another approach, the one used by JavaServer Pages, would be to use the HTML file as input to a converter program—one which would take each line of HTML, for example

<input name="name" size="20">

and produce a line of Java code:

out.println("<input name=\"name\" size=\"20\">");

Notice how the converter would be the one to handle the escape sequence for the quotation marks; we get to write straight HTML—it has to deal with the backslashes.

This is the basic idea behind JavaServer Pages. JSP files are nothing more than HTML (with some additions that we’ll discuss shortly) which are com- piled into Java programs—servlets, to be exact—that are then run to produce the Web page. The conversion happens no later than the first time the Web server tries to serve up that JSP. If it hasn’t yet been converted, it will convert it into Java code and start the servlet. Thereafter, other requests to that page go directly to the servlet. If you modify the JSP file, then the Web server recognizes that the file has been modified and reconverts it.

But why go to all this trouble? It’s not for the static HTML that we need JSP, but rather for the dynamic bits. Remember that for loop, above, used to make the HTML table of subaccounts? Let’s look at part of a JSP that does the same thing:

<table border=1 width=50%>






<% // for each subaccount:

for (Iterator actit = acct.getAllSubs(); actit.hasNext(); ) { Account suba = (Account) actit.next();



<td><a href="BPControl?name=<%= suba.getName() %>&func=cd">

<%= suba.getName() %>




<%= suba.getTotal().toString() %>




} // next acct



Notice how it starts off as simply the HTML building the table opening. Then we encounter some Java source code, enclosed in delimiters (<% ... %>), then back to plain HTML. There’s even a line which intermixes HTML and Java:

<td><a href="BPControl?name=<%= suba.getName() %>&func=cd">

To understand what’s going on here, let’s take a look at four pieces of syntax that are the keys to JSP.


Writing a JSP application consists, syntax-wise, of writing your desired output page in HTML and, where you need the dynamic bits, putting Java code and/or other special syntax inside special delimiters that begin with <%.

There are four special delimiters that we should describe if you’re going to work with JSP. The bulk of your JSP will likely be HTML. But interspersed among the HTML will be Java source or JSP directives, inside of these four kinds of delimiters:

<% code %>

<%= expression %>

<%! code %>

<%@ directive %>

Let’s look at them one at a time.


19.3.1 Scriptlet

19.3.2 Declaration

19.3.3 Expression

19.3.4 Directive

19.3.5 New Syntax

19.3.6 JavaBeans in JSP

19.3.7 Tag Libraries