Web Development with JavaServer Pages
Reusable components
Although JavaServer Pages enables programmers to implement dynamic
content generation
by including Java source code directly in web pages, it also includes
a set of
HTML-like tags for interacting with Java objects residing on the
server. In particular,
these tags are designed for creating, querying, and modifying
server-side JavaBeans.
JavaBeans are objects, written in Java, whose implementations
conform to a set
of conventions designed to promote modularity and reusability.
JavaBeans uses a
programming style that leads to self-contained chunks of program code
that encapsulate
related data, functionality, or behavior, which may be used and
reused in multiple
contexts without having to know the details of their inner operation.
As a
result, JavaBeans can readily be connected together and combined in
order to provide
more sophisticated or application-specific capabilities. The generic
computer
term for an object that exhibits this sort of plug-and-play
interoperability is a component.
JavaBeans, then, is one example of a component programming model.
Others
include Microsoft's ActiveX (which plays a similar role in Active
Server Pages to the
role of JavaBeans in JavaServer Pages) and CORBA, a component
interoperability
standard developed by the Object Management Group (OMG), an industry
consortium
for distributed, cross-platform, object-oriented middleware.
A component, then, is a stand-alone object representing a collection
of proper-ties
and behavior. Because these properties and behavior can be accessed
without regard for the underlying implementation, it is possible to
describe a component's
capabilities independent of the programming language in which it was
originally
written. A component could be used in a second programming language
(for example,
a scripting language), or even be applied using visual tools, with no
program
code at all. In the case of JavaServer Pages, components written as
JavaBeans are
accessed not by means of a programming language, but via an alternate
syntax. Specifically, JSP
provides HTML-like tags for accessing JavaBeans on a page, and for
displaying
and modifying their properties. For complete details, see chapter
5.
The primary virtue of component-centric design is reusability.
Because components
are required to be self-contained, programmers do not have to
understand
any complicated relationships between objects in order to be able to
use them. A
component may call on other objects behind the scenes, but the
abstract interface
through which the component is accessed and manipulated, if designed
properly,
will mask the underlying complexity. Because components tend to be
targeted
towards specific tasks- representing a particular set of data,
performing a specific
behavior- it is easy to determine what functionality the
component provides, and
therefore under what circumstances it should be used. To some extent,
components
are reused by virtue of the fact that they are easy to use in the
first place.
The benefit of this reusability is productivity. If a component is
already available
to perform some task, that is one less piece of code that needs to be
written,
debugged, and maintained. Furthermore, components are generally not
context-sensitive.
For example, the same JavaBean can be deployed in a servlet, an
applet, or
a JSP page, creating additional opportunities for reuse.
Separating presentation and implementation
By taking advantage of JSP's built-in support for JavaBeans, it
becomes possible to
maintain a strict separation between data presentation- the
display of information
to the end user- and program implementation- the code
used to generate that
information in the first place. The benefit of decoupling these two
aspects is that
changes to one can be made without requiring any changes to the
other. The way
data is displayed (e. g., font selection, color scheme, page layout)
can be revised
without ever having to modify any Java code. Similarly, as long as
the component
interfaces remain unchanged, the underlying implementation can be
rewritten (e. g.,
to improve performance or maintainability) with no effect on any JSP
pages that
use those components.
Given this goal, then, JSPs provide a very simple and elegant means
of maintaining
the separation of these two elements of a web-based application:
syntax. By
leveraging JSP's HTML-like tags for accessing JavaBeans and their
properties, JSP pages can be written that contain no Java source code. If none of
the available tags
provides the functionality needed, you can, if so inclined, write
your own application
specific tag library using the JSP tag extension mechanism. If the
JSP page
contains only tags and no Java code, the first requirement for
enforcing separation
of presentation and implementation has been met, since there is no
implementation
code mixed in with the presentation code.
The second requirement is equally easy to describe: there should be
no HTML
code in your JavaBeans. At first blush, this might sound like an
absurd notion.
(JavaBeans are written in Java, not HTML!) However, there's nothing
stopping a
programmer from creating a JavaBean whose properties include strings
of HTML
code. A JSP page could then access these properties, inserting that
HTML code into
the page through the corresponding property tags. It may be tempting
to give your
JavaBean the ability to, say, generate a large HTML table from the
results of a
database query, but any time it is necessary to change the appearance
of the table,
that Bean must be edited, compiled, and tested before that change can
be put into
effect. For this reason, in order to achieve separation of
presentation and implementation,
it's also necessary to keep presentation code out of the
implementation code.
There will be times, though, when generating HTML code
programmatically is
the best solution. Consider an on-line banking application
implemented via Java-Server
Pages. There would likely be JavaBeans representing a customer's
accounts,
as well as each of the transactions involving those accounts. For
maximum reusability,
good component-centric design would dictate that these
application-oriented
JavaBeans would model only the banking aspects of accounts and
transactions, and
would not include properties that return, say, account balances in
HTML format.
These Beans could then be readily deployed in other application
contexts (e. g., a
Java applet), which have no use for such web-oriented baggage. It
would likely
prove fairly cumbersome, however, to write a JSP page that uses these
Beans to display,
say, the last 10 transactions for an account. This is primarily
because JSP does
not include any built-in tags for iterating through Bean properties.
To solve this
dilemma, it appears that you have no choice but to either include
Java scripting
code in the JSP, or provide for HTML output by the Bean.
Fortunately, JavaServer Pages provides a third alternative,
specifically geared
toward programmatic generation of HTML using Java code. As suggested
in
figure 1.3, this is the role of JSP's tag extension mechanism, which
allows Java
programmers to implement new JSP tags and package them in
application-specific
libraries that may then be imported into individual JSP pages. For
this hypothetical
banking application, then, the best way to maintain separation
between presentation and implementation is to develop a set of custom tags
for representing
complex account information, such as transaction lists, via HTML.
Custom tags still have the problem that, in
order to change the display of data controlled
via custom tags, programming is required. This
is unavoidable, however, if programmatic generation
of HTML is required. The advantage of
implementing HTML generation via custom
tags is two-fold. First, custom tags provide a
means for avoiding Java code in the JSP files
themselves. JSP files can continue to rely on a
single, consistent, HTML-like syntax. Second,
on the programming side, the HTML generation
is isolated within the tag library code. The
tag library will likely have dependencies upon
your JavaBeans code, but not vice versa. Custom
tags provide a well-defined interface
between the presentation and implementation, without contaminating
the JSP files
with implementation code, or the Bean properties with presentation
code.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
