ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

JSP 1.2: Great news for the JSP Community, Part 1
Pages: 1, 2, 3, 4

JSP Pages, JSP Documents and XML Views

An important part of JSP 1.2 is the definition of an XML syntax for JSP. A JSP 1.2-compliant container must accept files in both the old JSP 1.1 format, now formally called a JSP Page, and the new XML format, formally called a JSP Document.



A JSP Document has a root element named <jsp:root> that defines the namespaces for the standard JSP elements and all custom tag libraries used in the page. All JSP directives and scripting elements must be represented by XML elements instead of the ASP-like elements used in a JSP Page:

<jsp:root 
 xmlns:jsp="http://java.sun.com/JSP/Page" 
 xmlns:demo="/demolib" 
 version="1.2"> 
 
 <jsp:directive.page contentType="text/html" /> 
 
 <ul> 
  <demo:myLoopTag items="myCollection" var="current"> 
   <li> 
     <jsp:getProperty name="current" property="lastName" />, 
     <jsp:getProperty name="current" property="firstName" /> 
   </li> 
  </demo:myLoopTag> 
 </ul> 
 
</jsp:root>

Besides JSP elements, such as the declaration and custom actions shown in this example, a JSP Document can also contain XML elements, such as XHTML elements. Examples here are the <ul> and <li> elements.

It's not in the scope of this article to describe the complete JSP Document syntax. Note, however, that it's much more verbose than the JSP Page syntax, and is primarily intended to be used by tools. If you still want to use this syntax, I recommend that you read section 5, JSP Documents, of the JSP 1.2 specification.

When a container receives a request for a JSP Page the first time, it converts it to an XML document, similar to a JSP Document, before it performs validation and conversion to a servlet. This XML document is formally called the XML View of the page. The only difference between an XML View and a JSP Document is that all template text is wrapped within <jsp:text> elements, using CDATA sections to prevent problems with special characters that may be used in the template text:

<jsp:root 
 xmlns:jsp="http://java.sun.com/JSP/Page" 
 xmlns:demo="/demolib" 
 version="1.2"> 
 
 <jsp:directive.page contentType="text/html" /> 
 
  <jsp:text><![CDATA[<ul> 
]]></jsp:text> 
    <demo:myLoopTag items="myCollection" var="current"> 
    <jsp:text><![CDATA[<li> 
]]></jsp:text> 
    <jsp:getProperty name="current" property="lastName" /> 
      <jsp:getProperty name="current" property="firstName" /> 
       </demo:myLoopTag> 
      <jsp:text><![CDATA[</ul> 
]]></jsp:text> 
 
</jsp:root>

The new TagLibraryValidator described later in this article uses the XML View to validate a JSP Page.

Tag Library Deployment and Distribution News

With JSP 1.2 also comes a couple of simplifications for deployment and distribution of tag libraries: auto-discovery of tag libraries and distribution of multiple libraries in one JAR file.

Auto-Discovery of Tag Libraries

In JSP 1.1, you could refer to a tag library by letting the taglib directive's uri attribute specify either the real path to the tag library or a symbolic name. If you used a symbolic name, you also had to map the name to the real path with the <taglib> element in the web.xml file for the application. JSP 1.2 adds a third, more powerful alternative: just drop the tag library JAR file in the WEB-INF/lib directory and use the library's standard URI in the taglib directive.

Here's how it works. The Tag Library Descriptor (TLD) includes a <uri> element that you use to define the standard URI for the library:

<taglib> 
  ... 
  <uri>/demo</uri> 
  ... 
</taglib>

When the Web application is started, the container scans through the WEB-INF directory structure for files ending with the extension .tld and all JAR files that contain files with the .tld extension in their META-INF directory. In other words, all TLD files. For each TLD, the container looks for the <uri> element and creates a map from the URI to the TLD that contains it. In your JSP page, you just have to place a taglib directive with a uri attribute value matching the URI in the TLD:

<%@ taglib uri="/demo" prefix="demo" %>

That's it! No more messing around with real paths (which may change, for instance, when you upgrade the library) in the JSP pages or web.xml tag library declaration woes.

Multiple Libraries in One JAR File

A beneficial side effect of the auto-discovery feature is that you can bundle more than one tag library in the same JAR file. In JSP 1.1, a TLD contained in a JAR file had to be named exactly META-INF/taglib.tld. This meant that a JAR file could only contain one TLD.

The auto-discovery feature, however, treats any file with a .tld extension in a JAR file's META-INF directory as a TLD. You can therefore put multiple TLDs (along with the class files for the libraries) in one JAR file. This makes it easier for your users to deploy related tag libraries. Note that you must use the auto-discovery mechanism to deploy multi-library JAR files, since there's no way to specify the path to an individual TLD in such a JAR file.

Pages: 1, 2, 3, 4

Next Pagearrow