O JSP T: Verview of Echnology
O JSP T: Verview of Echnology
TECHNOLOGY
Topics in This Chapter
Understanding the need for JSP
Evaluating the benefits of JSP
Comparing JSP to other technologies
Avoiding JSP misconceptions
Installing JSP pages
Surveying JSP syntax
Prentice Hall and Sun Microsystems Press. Personal use only. 303
10
JavaServer Pages (JSP) technology enables you to mix regular, static HTML with
dynamically generated content. You simply write the regular HTML in the normal
manner, using familiar Web-page-building tools. You then enclose the code
for the dynamic parts in special tags, most of which start with <%and end with %>.
For example, Listing 10.1 (Figure 101) presents a very small JSP page that uses a
request parameter to display the title of a book. Notice that the listing is mostly standard
HTML; the dynamic code consists entirely of the half line shown in bold in the
listing.
<!DOCTYPEHTMLPUBLIC"//W3C//DTDHTML4.0Transitional//EN">
<HTML>
<HEAD>
<TITLE>OrderConfirmation</TITLE>
<LINKREL=STYLESHEET
HREF="JSPStyles.css"
TYPE="text/css">
</HEAD>
<BODY>
<H2>OrderConfirmation</H2>
Thanksforordering<I><%= request.getParameter("title") %></I>!
</BODY></HTML>
You can think of servlets as Java code with HTML inside; you can think of JSP as
HTML with Java code inside. Now, neither servlets nor JSP pages are restricted to
using HTML, but they usually do, and this over-simplified description is a common
way to view the technologies.
Now, despite the large apparent differences between JSP pages and servlets,
behind the scenes they are the same thing. JSP pages are translated into servlets, the
servlets are compiled, and at request time it is the compiled servlets that execute. So,
writing JSP pages is really just another way of writing servlets.
Even though servlets and JSP pages are equivalent behind the scenes, they are not
equally useful in all situations. Separating the static HTML from the dynamic content
provides a number of benefits over servlets alone, and the approach used in
JavaServer Pages offers several advantages over competing technologies. This chapter
explains the reasons for using JSP, discusses its benefits, dispels some misconceptions,
shows you how to install and execute JSP pages, and summarizes the JSP syntax
discussed in the rest of the book.
Hey! you say, You just spent several chapters extolling the virtues of servlets. I like
servlets. Servlets are convenient to write and efficient to execute. They make it simple
to read request parameters and to set up custom code to handle missing and malformed
data. They can easily make use of HTTP request headers and can flexibly
manipulate HTTP response data. They can customize their behavior based on cookies,
track user-specific data with the session-tracking API, and talk to relational databases
with JDBC. What more do I need?
Well, this is a good point. Servlets are indeed useful, and JSP by no means makes
them obsolete. However, look at the list of topics for which servlets excel. They are all
tasks related to programming or data processing. But servlets are not so good at
presentation.
Servlets have the following deficiencies when it comes to generating the output:
10.2 Benefits of JSP 305
Prentice Hall and Sun Microsystems Press. Personal use only.
JSP pages are translated into servlets. So, fundamentally, any task JSP pages can perform
could also be accomplished by servlets. However, this underlying equivalence
does not mean that servlets and JSP pages are equally appropriate in all scenarios.
The issue is not the power of the technology, it is the convenience, productivity, and
maintainability of one or the other. After all, anything you can do on a particular
computer
platform in the Java programming language you could also do in assembly language.
But it still matters which you choose.
JSP provides the following benefits over servlets alone:
It is easier to write and maintain the HTML. Your static code is
ordinary HTML: no extra backslashes, no double quotes, and no
lurking Java syntax.
You can use standard Web-site development tools. For example,
many auxiliary libraries. In addition, many developers still use the original version of
ASP. With this version, JSP has a clear advantage for the dynamic code. With JSP, the
dynamic part is written in Java, not VBScript or another ASP-specific language, so
JSP is more powerful and better suited to complex applications that require reusable
components.
You could make the same argument when comparing JSP to the previous version
of ColdFusion; with JSP you can use Java for the real code and are not tied to a
particular
server product. However, the current release of ColdFusion is within the context
of a J2EE server, allowing developers to easily mix ColdFusion and servlet/JSP
code.
Versus PHP
PHP (a recursive acronym for PHP: Hypertext Preprocessor) is a free, open-source,
HTML-embedded scripting language that is somewhat similar to both ASP and JSP.
One advantage of JSP is that the dynamic part is written in Java, which already has an
extensive API for networking, database access, distributed objects, and the like,
whereas PHP requires learning an entirely new, less widely used language. A second
advantage is that JSP is much more widely supported by tool and server vendors
than is PHP.
Versus JavaScript
JavaScript, which is completely distinct from the Java programming language, is
normally used to dynamically generate HTML on the client, building parts of the
Web page as the browser loads the document. This is a useful capability and does
not normally overlap with the capabilities of JSP (which runs only on the server).
JSP pages still include SCRIPTtags for JavaScript, just as normal HTML pages do.
In fact, JSP can even be used to dynamically generate the JavaScript that will be
sent to the client. So, JavaScript is not a competing technology; it is a complementary
one.
It is also possible to use JavaScript on the server, most notably on Sun ONE (formerly
iPlanet), IIS, and BroadVision servers. However, Java is more powerful, flexible,
reliable, and portable.
portability, integration, industry support, and technical features. The arguments for
JSP alternatives have focused almost exclusively on the technical features part. But
portability, standardization, and integration are also very important. For example, as
discussed in Section 2.11, the servlet and JSP specifications define a standard directory
structure for Web applications and provide standard files (.war files) for deploying
Web applications. All JSP-compatible servers must support these standards.
Filters (Volume 2) can be set up to apply to any number of servlets or JSP pages, but
not to nonstandard resources. The same goes for Web application security settings
(see Volume 2).
Besides, the tremendous industry support for JSP and servlet technology results
in improvements that mitigate many of the criticisms of JSP. For example, the JSP
Standard Tag Library (Volume 2) and the JSP 2.0 expression language (Chapter 16)
address two of the most well-founded criticisms: the lack of good iteration constructs
and the difficulty of accessing dynamic results without using either explicit Java code
or verbose jsp:useBeanelements.
In this section, we address some of the most common misunderstandings about JSP.
You do not need Java I/O to read image files; you just put the
image in the directory for Web resources (i.e., two levels up from
WEB-INF/classes) and output a normal IMGtag.
You create images that change under the mouse by using client-side
JavaScript, referenced with the SCRIPTtag; this does not change just
because the server is using JSP.
Browsers do not support JSP at allthey merely see the output of
the JSP page. So, make sure your JSP outputs HTML compatible with
the browser, just as you would do with static HTML pages.
And, of course you need not do anything to prevent clients from
seeing JSP tags; those tags are processed on the server and are not part
of the output that is sent to the client.
called
_jspService
called
Page first written
Servlets require you to set your CLASSPATH, use packages to avoid name conflicts,
install the class files in servlet-specific locations, and use special-purpose URLs. Not
so with JSP pages. JSP pages can be placed in the same directories as normal HTML
pages, images, and style sheets; they can also be accessed through URLs of the same
form as those for HTML pages, images, and style sheets. Here are a few examples of
default installation locations (i.e., locations that apply when you arent using custom
Web applications) and associated URLs. Where we list SomeDirectory, you can use
any directory name you like, except that you are never allowed to use WEB-INF or
META-INF as directory names. When using the default Web application, you also have
to avoid a directory name that matches the URL prefix of any other Web application.
For information on defining your own Web applications, see Section 2.11.
Corresponding URL.
http://host/SomeDirectory/SomeFile.jsp
install_dir/servers/default/default-ear/default-war
Corresponding URL.
http://host/SomeFile.jsp
Corresponding URL.
http://host/SomeDirectory/SomeFile.jsp
Corresponding URL.
http://host/SomeFile.jsp
Corresponding URL.
http://host/SomeDirectory/SomeFile.jsp
Note that, although JSP pages themselves need no special installation directories,
any Java classes called from JSP pages still need to go in the standard locations used
by servlet classes (e.g., .../WEB-INF/classes/directoryMatchingPackageName; see Section
2.10). Note that the Java classes used by JSP pages should always be in packages;
this point is discussed further in later chapters.
314 Chapter 10 Overview of JSP Technology
Prentice Hall and Sun Microsystems Press. Personal use only.
Here is a quick summary of the various JSP constructs you will see in this book.
HTML Text
Description:
HTML content to be passed unchanged to the client
Example:
<H1>Blah</H1>
Discussed in:
Section 11.1
HTML Comments
Description:
HTML comment that is sent to the client but not displayed by the
browser
Example:
<!Blah>
Discussed in:
Section 11.1
Template Text
Description:
Text sent unchanged to the client. HTML text and HTML comments
are just special cases of this.
Example:
Anything other than the syntax of the following subsections
Discussed in:
Section 11.1
JSP Comment
Description:
Developer comment that is not sent to the client
Example:
<%Blah%>
JSP Expression
Description:
Expression that is evaluated and sent to the client each time the page
is requested
Example:
<%=Java Value %>
Discussed in:
Section 11.4
JSP Scriptlet
Description:
Statement or statements that are executed each time the page is
requested
Example:
<%Java Statement %>
Discussed in:
Section 11.7
JSP Declaration
Description:
Field or method that becomes part of class definition when page is
translated into a servlet
Examples:
<%!Field Definition %>
<%!Method Definition %>
Discussed in:
Section 11.10
JSP Directive
Description:
High-level information about the structure of the servlet code (page),
code that is included at page-translation time (include), or custom
tag libraries used (taglib)
316 Chapter 10 Overview of JSP Technology
Prentice Hall and Sun Microsystems Press. Personal use only.
Discussed in:
page: Chapter 12
include: Chapter 13
tagliband tag: Volume 2
JSP Action
Description:
Action that takes place when the page is requested
Example:
<jsp:blah>...</jsp:blah>
Discussed in:
jsp:includeand related: Chapter 13
jsp:useBeanand related: Chapter 14
jsp:invokeand related: Volume 2
${EL Expression }
Discussed in:
Chapter 16
Discussed in:
Volume 2
10.6 Basic Syntax 317
Prentice Hall and Sun Microsystems Press. Personal use only.
Discussed in:
Section 11.1