3.1 The Problem with Servlets
In many Java servlet-based applications, processing
the request and generating the response are both handled by a
single servlet class. Example
3-1 shows how a servlet class often looks.
Example 3-1. A typical
servlet class public class OrderServlet extends HttpServlet {
public void doGet((HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter( );
if (isOrderInfoValid(request)) {
saveOrderInfo(request);
out.println("<html>");
out.println(" <head>");
out.println(" <title>Order Confirmation</title>");
out.println(" </head>");
out.println(" <body>");
out.println(" <h1>Order Confirmation</h1>");
renderOrderInfo(request);
out.println(" </body>");
out.println("</html>");
}
...
If you're not a programmer, don't worry about
all the details in this code. The point is that the servlet
contains request processing and business logic (implemented by
methods such as isOrderInfoValid( ) and
saveOrderInfo( )), and also generates the response
HTML code, embedded directly in the servlet code using
println( ) calls. A more structured servlet
application isolates different pieces of the processing in
various reusable utility classes and may also use a separate
class library for generating the actual HTML elements in the
response. Even so, the pure servlet-based approach still has a
few problems:
-
Thorough Java programming knowledge is
needed to develop and maintain all aspects of the
application, since the processing code and the HTML elements
are lumped together.
-
Changing the look and feel of the
application, or adding support for a new type of client
(such as a WML client), requires the servlet code to be
updated and recompiled.
-
It's hard to take advantage of web-page
development tools when designing the application interface.
If such tools are used to develop the web page layout, the
generated HTML must then be manually embedded into the
servlet code, a process which is time consuming, error
prone, and extremely boring.
Adding JSP to the puzzle lets you solve these problems by
separating the request processing and business logic code from
the presentation, as illustrated in Figure
3-1. Instead of embedding HTML in the code, you place all
static HTML in a JSP page, just as in a regular web page, and
add a few JSP elements to generate the dynamic parts of the
page. The request processing can remain the domain of the
servlet, and the business logic can be handled by JavaBeans
and EJB components.
As I mentioned before, separating the request
processing and business logic from presentation makes it
possible to divide the development tasks among people with
different skills. Java programmers implement the request
processing and business logic pieces, web page authors
implement the user interface, and both groups can use
best-of-breed development tools for the task at hand. The
result is a much more productive development process. It also
makes it possible to change different aspects of the
application independently, such as changing the business rules
without touching the user interface.
This model has clear benefits even for a
web-page author without programming skills, working alone. A
page author can develop web applications with many dynamic
features, using the JSP standard actions and the JSTL
libraries, as well as Java components provided by open source
projects and commercial companies.
|