Custom tags in JavaServer Pages have come a long way since their inception. Now that Sun has provided some standards for these tags in the form of JSTL (and the up-and-coming JavaServer Faces), and has promised additional support for these standards in JSP 2.0, let's look at how we got to this point in tag history, and where we're going in the future. (In addition, let's look at how we can use the JSTL taglibs and the Struts Taglibs that support the JSTL expression language right now.)

Tag-based approaches to Web application development are nothing new. Their origins can be traced back to HTML (since they mimic HTML's syntax), and are represented by such varied approaches as SSI, Macromedia's ColdFusion, Microsoft's Active Server Pages (ASP), and, of course, JSP.

JSP: Model 1 vs Model 2
One of the big problems with JSP Model 1 was that it lent itself to bloated "monolithic JSPs" that combine programming logic and presentation format in one module. Monolithic JSPs violate the principle of "Separation of Content from Presentation," to be sure. It's only when you have to maintain such JSPs in production applications that you begin to understand the importance of that principle in practice.

JSP Model 2 is an approach to Web application development that adheres to the Model-View-Controller (MVC) paradigm. Sun's vision for Model 2 is that the controller would be a servlet, the model would be represented by JavaBeans (or EJBs in more sophisticated applications), and the view would be comprised of JSPs that contain only presentation formatting constructs (i.e., no code). The presence of Java code in a JSP leads to the previously mentioned "monolithic JSP" syndrome, where data access and manipulation logic that belongs in the controller or model component of the application finds its way into the view component (the JSP). The intermixing of code with presentation formatting constructs results in a cluttered, unwieldy page that's not only difficult to maintain, it's not clear who is supposed to maintain it.

Custom JSP tags, a feature added to the JSP specification in version 1.1, makes it possible to achieve this desired separation of code from formatting. By encapsulating functionality in a single atomic entity that can perform complex processing that would have required a substantial amount of Java code, tags reduce (if not eliminate) the amount of code within a JSP page. (By code, I mean both scriptlets and the awkward JSP "expression" statements that make simple variable assignments more cumbersome than necessary.)

Well-designed tags allow a page designer to address and access data from the model that's constructed and manipulated by the controller. The decision about which data goes into the model (and which JSP view to employ for presentation) is in the hands of the controller. Thus, all a JSP developer needs to worry about is the layout of data already accessed and organized for presentation. (At least, that is the ideal - MVC frameworks encourage but do not enforce this separation.)

Historical Perspective: Programmatic and Template Approaches
Let's briefly examine how we got to where we are today, and what part tags played in this story.

Historically, Web application development approaches have fallen into two broad categories: programmatic approaches and template-oriented approaches. CGI (especially Perl CGI scripts) and the Servlet API fit into the programmatic category. Server Side Includes (SSI) and proprietary frameworks like ColdFusion fit into the template category.

The defining difference between these approaches is the focus of the page presentation object - the "view" in Model-View-Controller parlance. If the primary content of the view component is code, interspersed with a few HTML formatting constructs, then we are talking about a programmatic approach. If the view component is basically an HTML page (or a page in some other target language such as WML or SMIL), with some embedded programming constructs, then we're talking about a template approach. More often than not, a template approach would make use of specialized tags that looked like HTML but were not part of the HTML language. These were server-side tags that performed conditional processing, iteration over a set of query results, and other complex application functions.

Naturally, these are arbitrary categorizations, and few approaches fit neatly into either one. PHP, for example, is often referred to as a template approach, yet a PHP module often contains more code than formatting. A ColdFusion module, on the other hand, looks structurally like an HTML page, but many also contain database queries in SQL.

Hybrid Approaches
Hybrid approaches abound, trying to be the best of both worlds by including page formatting and code constructs in one module. Microsoft's Active Server Pages and Sun's JavaServer Pages (specifically JSP Model 1) fit into this nebulous category, and both are, of course, very popular.

However, this combination of code and formatting in one module often hurts rather than helps. First, it's a violation of the aforementioned principle of "Separation of Content from Presentation." Having both content and presentation in the same module binds the content to a single presentation format. If a new presentation format is desired - either a new HTML page layout or a completely different format such as XML/XSLT - a new module that replicates a good portion of the old module must be created. Such replication naturally lends itself to problems as the application grows more complex. (The ability to include common page fragments that access and manipulate content helps us somewhat, but does not eliminate the problem.)

Then there is the question of "who owns this module?" Is it the Web designers, who are responsible for the page design and layout? Or the programmers, who are responsible for providing dynamic access to the data that populates the page? If designers want to modify the page layout, do they get to modify the ASP or JSP page themselves? If programmers need to change the code within an ASP or JSP page, what do they do if that change breaks the page presentation?

In practice, designers produce HTML mockups of pages that are then translated into JSPs by programmers. This means that even the slightest change to a page layout requires a remockup of the page layout that's then retranslated into an ASP or JSP by programmers. What a waste of resources! Every time the page layout changes, a programmer must get involved, tweaking (or totally reworking) the ASP or JSP page. Why?

Because for all the hype about ASPs and JSPs being "friendlier" than pure programmatic solutions like CGI scripts and Java servlets, they aren't so "friendly" that you would hand them to page designers to work on themselves. This is partly because both ASPs and JSPs have historically required the inclusion of significant amounts of code to perform their tasks, and designers are generally not trained as programmers.

Tag, You're It
It's practically impossible to eliminate programming constructs from such a page entirely - how could we support variable content on a page (including a variable number of rows displayed from the results of a database query) without logic constructs that support iteration and conditional processing? Sure, we could write code that produced a complete HTML table containing the formatted results of a query, but this is another violation of the content/presentation separation principle. Programmers are writing HTML in their code - the very thing we're trying to get away from. Furthermore, page designers have very little control (beyond CSS styles) over the presentation of an already formatted table.

Tag-based approaches are one solution to this problem. A small set of tags that support conditional processing, iteration, external resource inclusion, and common formatting tasks could be developed. Macromedia's ColdFusion product, originally developed by the Allaire Corporation, gained popularity by providing such tags as part of its application platform. ASP and JSP followed suit, but did not provide all the necessary puzzle pieces (i.e., code was still needed within ASP and JSP pages to perform most nontrivial tasks).

Both Sun and Microsoft sought to fill that gap by offering developers the capability of designing their own custom tags. (ASP calls them "custom controls".) This capability came without a lot of guidance from the vendors, and standards have been slow in coming. While a product like ColdFusion already had well-defined iterative and conditional constructs, JSP and ASP developers had to construct their own.

The developers of Struts, an MVC/Model 2 framework from the Apache Jakarta project, wrote their own set of tag libraries that provided a variety of powerful functionality. These included tags to perform processing logic (struts-logic), production of HTML elements (struts-html), and interaction with JavaBeans (struts-bean). They have been available since the release of Struts 1.0 and served to fill in many of the gaps that were present in the JSP development process. As Struts' popularity grew, so did the need for standard tags that performed these functions in a consistent way across all JSP-based applications, not just those written in Struts.

Sun finally came through with some guidance of their own: a specification for a standard set of tags known as the Java Standard Tag Library (JSTL). The tag specifications combine the functionality associated with some of the Struts taglibs with many of the original ColdFusion tags. In addition to the tags themselves, the JSTL specification also defines an expression language (EL) for accessing data components from the request context using a simplified notation that is a major improvement over code-oriented methods for accessing such data.

Jakarta developers who had been working on other taglib projects built a reference implementation for JSTL, which is now readily available and is included with many Jakarta project distributions. But JSTL is not the end of the story. Currently, there's another project, called JavaServer Faces (JSF), that is seeking to standardize the presentation of page formatting elements in a fashion similar to the existing struts-html taglib.

Let's focus on how the evolution of JSP custom tags has ameliorated the Web application development process by improving the structure of JSP pages to make them less code-centric and more MVC-compliant. JSTL is not a panacea, and JSF should not be expected to be one either, but looking at this evolution will help us understand where we are likely to go next.

Examples: Curing the Common Code
Let's begin with a fragment from a classic Model 1 JSP page. While it's deemed a good idea to eliminate Java code embedded within JSPs, this is easier said than done. Accessing JavaBean properties and including them in the page response, for example, can easily be accomplished within a scriptlet using JavaBean accessor methods and variable substitution.

<%
MyBeanClass myBean = (MyBeanClass)
session.getAttribute("myBean") ;
String type = myBean.getType() ;
String imageUrl = myBean.getImageUrl() ;
%>
<B>The value of the type property of myBean is <%= type %>.
</B>
<P><IMG SRC="<%= imageUrl %>">

In the fragment above, a scriptlet accesses a session attribute (a JavaBean stored in the session with the name "myBean") and establishes it within the page context. It then assigns the values of some of the bean's properties to other variables. Using the <%= ... %> expression syntax, the values of these properties are included in the page.

Obviously this will not render reasonably when previewed in a Web browser. Not only are "type" and "imageUrl" variables whose values cannot be determined except in the context of a running application, but also their presence within the page is bounded by greater-than and less-than signs, just like HTML tags. Web browsers will see these and assume they have simply come across a new tag they haven't been designed to handle. (The <NOSCRIPT> and <NOEMBED> tags make use of this feature to provide a degree of backward compatibility for older browsers.) Most browsers simply ignore such "tags" and pretend they aren't there, thus an attempt to display this page in a browser will result in gibberish. Furthermore, the expression intended to display the image URL tag ("<%= imageUrl %>") is embedded inside an HTML <IMG> tag, which is a violation of XML formatting constraints.

Step 1: JSP Standard Actions
Sun created a set of JSP "standard actions," which are tags that allow JSP pages to cooperate with JavaBeans, perform page redirection, and include external resources. In contrast to the original set of JSP directives (which used an ASP-like syntax beginning with "<%"), these new tags adhere to an XML-compliant format. They use the "jsp" namespace to specify tags to define and access a JavaBean (e.g., <jsp:usebean name="bean1" scope="session" ... />), and access bean properties (e.g., <jsp:getProperty name="bean1" property="prop1" />).

<jsp:useBean name="myBean" scope="session"
class="mypackage.MyBean"/>
<B>The value of the type property of myBean
is <jsp:getProperty name="myBean"
property="type" />.</B>
<P><IMG SRC="<jsp:getProperty name="myBean"
property="imageUrl" />">

This second example uses the XML directive syntax for standard JSP actions, including the <jsp:useBean> and <jsp:getProperty> tags. The jsp:usebean tag does what the first statement from the first example does: it accesses a session attribute named "myBean" and defines it to the page. Instead of using the awkward <%= ... %> syntax, this page makes use of <jsp:useBean> and <jsp:getProperty> tags.

This page has eliminated at least one problem: scriptlets have been removed from the page. Note, however, that the <IMG> tag still contains a nested tag, <jsp:getProperty>, which is still a violation of XML formatting constraints. While most browsers today are tolerant of such violations in general, applications that generate XHTML for dynamic pages could not handle this notation. <jsp:getProperty> is in some ways an improvement over <%= ... %>, but it leaves many problems unresolved.

Although we have gotten rid of scriptlets for this example, it's much more difficult to remove them from more sophisticated pages. Let's imagine that "myBean" could have as one of its properties a Java Collection object that the page could iterate through. It may or may not have this property, though, and one simple way to tell is the use of the isMultiple() method, which returns true if this Collection property is populated.

The page snippet in Listing 1 shows how that would be done using scriptlets. We have inserted the output associated with iterating over the collection between the section of the page displaying the "type" property and the section displaying the image.

To call this ugly is an understatement. There is a six-line block of Java code that precedes a single line of HTML (which itself has a JSP expression embedded within it). Following this is a scriptlet block consisting of just the closing braces for the while loop and if statement. There is no "pretty" way to format "<%" and "%>", which are the strings that separate code from HTML in a JSP. Some code formatting standards exist that make the separation between code and formatting more distinct, but they are difficult to apply and don't resolve the problem entirely.

After seeing code like that in Listing 1, you have to wonder about the assertion that JSPs are presentation-view components that could theoretically be constructed by Web designers. Looking at the attempt to include HTML formatting within this block (line 12), you might think we'd have been better off replacing that line with more code (i.e., an out.println statement), and forgoing the notion of embedding HTML entirely!

Step 2: Custom Tags (Struts Taglibs)
With the advent of JSP 1.1 came the ability to write custom tags. As mentioned earlier, Sun provided the capability, but not much in the way of guidance and standards. Along came the Struts Taglibs, which provided standard ways to perform iterative and conditional processing. They provided a reusable set of tags that could be employed in a variety of applications, and a simpler notation for accessing properties of referenced JavaBeans. Since the lack of tags to perform these functions was one of the main reasons that scriptlets were overused, the Struts Taglibs represented a big step toward reducing the amount of code within JSP pages (see Listing 2).

While this was a vast improvement over what came before it, even greater improvements were on the horizon. Sun got the message that providing the ability to write custom JSP tags was nice, but providing standard sets of tags to perform common functions was just as important. With this in mind, they wrote a specification for a Java Standard Tag Library (known as JSTL).

Step 3: JSTL
The JSTL tags fit into four categories: core (output, variable setting and removal, inclusion, iterative and conditional processing), XML (all of the above but with an XML orientation, plus XSLT transformation and XPath processing), SQL (creating database queries and processing result sets), and formatting (internationalization, localization, and other custom formatting). In addition, JSTL defines an expression language (often called "EL") for accessing components directly in a class-agnostic, type-neutral manner, without excessive calls to intermediate tags and directives. For example, the notation "${sessionScope.brillig.borogoves[3].mimsy}" addresses the property named "mimsy" from the third element in the indexed property called "borogoves" that's found in the session attribute named "brillig".

<%@ taglib uri="/WEB-INF/c.tld" prefix="c" %>
<c:if test="${sessionScope.myBean.multiple}">
<c:forEach var="nb" items="$
{sessionScope.myBean.collection}">
<B><c:out value="${nb.name}" /></B>
</c:forEach>
</c:if>

The page fragment above offers a small sample of the functionality available from JSTL.

The Jakarta Taglibs project has provided a number of other useful tags, some of which have historically overlapped with Struts Taglib functionality, but many of which are useful in their own right. They took it upon themselves to write the reference implementation for the JSTL tag set, which is available from the Apache project Web site (www.apache.org/dist/jakarta/taglibs/standard-1.0/).

In addition, the developers of Struts also took it upon themselves to rewrite their own taglibs to use the JSTL expression language for parameter substitution. For backward compatibility, the original taglibs still exist and are the default set provided with the Struts distribution. To use the new versions of the taglibs that support the EL, special action must be taken when configuring your application, as described later. The page fragment in Listing 3 uses both JSTL core tags and the version of the struts-html taglib that provides EL support (the <html:img> tag) to provide a complete version of the original page fragment example using only JSTL and struts-html tags.

Step 4: JavaServer Faces
JavaServer Faces (JSF) is a relatively new specification from Sun (JSR 127) that hopes to provide even more innovations. Though JSF is still an immature technology - an early access release was provided late in 2002 - it shows a good deal of promise. Pioneers who make use of this early release of JSF are virtually guaranteed to have their code obsoleted as the specification mutates and matures. Still, it's a technology worth examining.

JSF appears at first glance to be a standardized plug-in replacement for the struts-html tag library, which provides a mechanism for pages containing HTML forms to interact with Struts Action classes. The goals for JSF go far beyond this. In fact, in the not too distant future, Struts will quite likely embrace both JSF and JSTL, converging on these standards instead of providing its own set of Struts-specific taglibs. JSF has more properly been called a cross between Struts and Swing, providing a framework for creating and manipulating generalized user interface components, including event handling and state management, in the context of an MVC-oriented Web application.

The capabilities provided with JSF include:
1.   An MVC approach complete with a Struts-like controller servlet and request life cycle
2.   A standardized user interface component model that makes JSF roughly analogous to Swing for HTML pages
3.   A validation framework providing functionality similar to Struts' Validator API

JSF is not tied to a particular presentation technology (e.g., JSP), but it does provide a tag library of formatting-language-neutral user interface components for use in JSPs. In other words, while the tags in the struts-html tag library were bound specifically to HTML elements, JSF tags are agnostic about which target formatting language will be used to render your page. There is a default "RenderKit" that produces HTML 4.01, but this is certainly only the beginning. Sun intends for vendors to provide custom RenderKits for other target formats, allowing the same JSF-enabled JSP page to be used for rendering in HTML, WML, SMIL, etc. (Note that to perform complex state management, event handling, and validation of UI components in HTML pages, JSF interacts with standardized JavaScript functions included on the page.)

Listing 4 is an example of a JSF page derived from the latest version of the JavaServer Faces Technology Tutorial available from Sun (http://java.sun.com/j2ee/javaserverfaces/docs/JSF.pdf). The specification for JSF is changing rapidly, and it's already known to be out of sync with the reference implementation, so use this example only as a guideline for what JSF pages are likely to look like when the technology matures.

Note that JSF tags are not only specialized in terms of the specific HTML element they correspond to (e.g., <input type="text">), but also in terms of what types of validation are performed for the tag. The <h:input_number> tag in the listing corresponds to an <input type="text"> tag, but it's also tied to JavaScript validation that ensures that the contents of the field are numeric. JSF includes not only form-oriented tags (<h:input_*>), but also tags for static display (<h:output_*>) and layout (<h:panel_*>).

While JSF technology is still in its infancy, it merits close observation as its specification becomes more stable. You can expect that increased synergy between JSF and JSTL will be a major factor in the acceptance of both technologies.

Where Do We Go from Here?
1.   Sun has already announced that JSP 2.0 will provide integrated support for the JSTL expression language anywhere within a JSP page. What would be nice is native support for JSTL, where the JSTL tags are as much a part of the core JSP syntax as tags already are. This means developers and administrators would not need to take extra steps to install or configure these taglibs, or provide taglib directives for them within pages.
2.   How about a tag that translates all EL expressions within the body? It seems like a real pain to write a <c:out> tag for every EL variable that's being included in a presentation. You could include a whole block of text (containing multiple EL expressions) as the "value" parameter of a <c:out> tag, but sometimes that's impractical (e.g., if the block of text contains HTML tags).

ColdFusion's <CFOUTPUT> tag turns variable substitution on for just the block of text found between its opening and closing tags (the "body" of the tag). A JSTL tag that does this same thing would be very nice indeed.

<c:output>
Here is the image for <B>${sessionScope.x.name}</B>:
<IMG SRC="${sessionScope.x.imageUrl}">
</c:output>
It can be found in the session attribute addressed by ${sessionScope.x}.

Yes, JSP 2.0 will provide this, but it will be a while before most JSP containers are compliant with 2.0 specifications. Furthermore, we might want to be selective about which parts of the page should participate in this variable substitution, e.g., the last line in the example above, where we want the string "${sessionScope.x}" to appear "as is."

3.   How about the ability to choose your own delimiters for the expression language? A notation like ${pageScope.object.attribute} may seem natural to Unix veterans, but (even though I qualify as one myself) I prefer a symmetric notation (e.g., [[pageScope.object.attribute]]), and I think many Web designers (who are supposedly the ultimate audience for JSTL-driven pages) are likely to agree. A possible syntax is offered in the following example.

<jsp:directive.taglibConfig el-delims="[[,]]" />

4.   While we're on the subject of Web designers and JSTL, how about integrated support for JSTL and the Expression Language in Web design tools? Dreamweaver and other popular tools already provide support for a variety of platforms including JSP, but a browser preview function that understands JSTL iterative and conditional tags and displays a reasonable mockup of the final page complete with "dummy" content would be a major step in enabling designers to gain full control over JSPs as presentation components.

Conclusion
In an MVC approach to Web application development, separation of content from presentation is critical. The key to this separation is a clear definition of responsibilities, with programmers responsible for model and controller components, and page designers responsible for view components. Code embedded in view components, as found in monolithic Model 1 JSPs, makes it impossible for designers to have true autonomous responsibility for those components. A tag-based approach that eliminates code from JSPs facilitates the separation of responsibilities and enables each group, designers and programmers, to do their job without stepping on each other's toes.

We've only scratched the surface in describing the capabilities of JSTL. I've only demonstrated a small number of the available core tags and barely mentioned the XML, SQL, and formatting tag libraries. I have only given a brief nod to JavaServer Faces, the up-and-coming Sun-endorsed specification that standardizes and augments the functionality found in a number of the other Struts tag libraries. JSTL, JSF, and JSP 2.0 all represent major advancements in the arena of Web application development, but it is the synergy between them that will see the greatest advancements.

Installing JSTL and Struts Taglibs with EL Support
To use JSTL and the versions of Struts Taglibs that support the JSTL Expression Language:
1.   Get the latest Struts distribution from the Jakarta project Web site (http://jakarta.apache.org/struts).
2.   Copy all of the *.jar files out of the /lib directory into the WEB-INF/lib directory used in building/deploying your application.
3.   Copy all the *.jar files out of the contrib/struts-el/lib directory into the WEB-INF/lib directory used in building/deploying your application. This will overwrite some of the JAR files you just placed there, replacing them with the EL-compatible versions.
4.   Copy all of the *.tld files out of the contrib/struts-el/lib directory into the WEB-INF directory used in building/deploying your application. This will include TLD files for the Struts Taglibs, the versions of the Struts Taglibs that support the JSTL expression language, and the JSTL taglibs themselves.
5.   When building your application's web.xml file, provide Taglib definitions for the JSTL Taglibs and the versions of the Struts Taglibs that support JSTL EL, as shown in Listing 5.
6.   Reference the appropriate TLDs in your taglib directives within your JSPs (see Listing 6).

• Source Code