Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

Servlet Presentation Programming

The servlet environment is responsible for integrating all Java application servers with the outside world. It was, after all, the publishing of the servlet API that gave Web servers the capability to be extended with object-oriented Java functionality. Although many developers are just now entering the world of servlet development, a significant portion of the Java community has expanded its attention to consider what it means to support modern application servers that give the developer the capability to create multi-tier application architectures. Even the application servers themselves are moving past proprietary APIs to well-defined standards reflected in specifications, such as J2EE.

Basic servlet programming, with the introduction of standard Java print statements, can be quite effective for building CGI scripting-like presentations. Let's face it. Sometimes you just want to get a simple job done, and the point of your task is to create something quick and dirty without requiring the services of an HTML designer. Embedding HTML strings directly into a servlet is one way to quickly generate a markup presentation, especially if your goal is to build a one-off application in a hurry.

Servlet programming for creating presentations is very reminiscent of Perl CGI programming. HTML is delivered by out.print() and out.println() methods. Logic is clearly intermingled with markup language and content. In scenarios like this, there's usually no requirement for a compelling Web presentation or a long product lifecycle.

In an example of extremely tight coupling that might be cynically referred to as strangulation by the integration of markup and programming logic, Listing 3.1 shows markup language as explicitly printed from Java logic.

Listing 3.1 Simple HTML Presentation Development with Servlet Programming

// Servlet imports
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse; 
// Standard imports
import java.io.*;
public class WelcomeServlet extends HttpServlet {
  public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException
    PrintWriter out = response.getWriter();
    out.println("<HEAD><TITLE>Enhydra XMLC Programming</TITLE></HEAD>");
    out.println("<P>"Welcome to today's class"</P>");
    if (scheduleDay.equals("Saturday") {
        out.println("<HEAD><TITLE>Servlet Programming</TITLE></HEAD>");
        out.println("<P>"No class on Saturday"</P>");

Servlet Web application development was greatly improved with the introduction of the servlet 2.2 specification, which introduced the notion of response buffering, giving the program the capability to flush the resultant markup page only when the processing of the page has been smoothly concluded.

If an error is encountered, the servlet has the option of taking a different path, such as creating a friendly HTML page indicating the nature of the error encountered. In either event, the servlet now has the capability to pre-build the page before deciding to flush it back to the client or not. Listing 3.1 also shows how the method reset() can be used to reset the output buffer.

The presentation strategy that pure servlet programming implements is relatively simple, and should be familiar to long-time Web developers who have used Perl sometime in the past.


Yes, you can use Enhydra for standard servlet development. Enhydra supports servlet 2.2 (as well as JSP 1.1 development). All the examples in this chapter were tested using Enhydra.

The implications of this style of presentation development are obvious. Servlets do not benefit from the presentation-specific features of JSP and XMLC. Usually, the page is designed by the trial and error method of directly typing HTML tags, or by the manual process of transposing the output from an HTML design tool into the source file.

There really is no notion of a template mechanism in this style of presentation development. For instance, there's no dynamic loading of a template depending on what type of presentation device is detected.

This kind of presentation development should be reserved for only the simplest of dynamic Web applications. If the application starts to take on a life of its own, switch to JSP or XMLC immediately. These presentation technologies are so easy to use and are so well supported by design tools, there's little reason left for presentation development by pure servlet programming.

  • + Share This
  • 🔖 Save To Your Account