XML, XPath, XSL, and StyleScript

Looking back at the last example in Chapter 4, you see that the JSP template used to display a user's account history has quite a bit of Java code embedded in it. If you want to accomplish the goal of providing good separation of tasks, you should remove as much of the Java code as possible and allow the Web designers to work with tags instead of code. Resin supplies a technology called XML Templates (XTP) to aid in this goal. In this chapter, we look at how XTP can be developed to give Web designers a host of tags for designing pages using data produced from business servlets in a full-featured system.

The Hello World XTP

Before we get into the details of cleaning up our account history example, let's look at our traditional Hello World application. The basic idea behind XTP is to create custom tags that you can use when creating presentation pages for a site and to hide all of the tag details. This allows the Web designer to use the tags in creating the presentation pages while giving the Web developer the ability to change the functionality of the tags or fix bugs without interference. The Resin server handles all of the details.

Figure 5.1 shows an example of an XTP page moving through the Resin server.

Figure 5.1: XTP processing through Resin.

When users requests an XTP page using their Web browser, the Web server part of Resin or an external server acknowledges the existence of the XTP page by passing it to a Resin XTP processor. This processor is responsible for replacing all of the XTP tags with its underlying code. This processor uses an XSL style sheet, which it applies to the original XTP page. The result of the processing is a JSP page. The JSP is converted to a servlet and compiled. Finally, the resulting servlet is executed. The result is an HTML page sent to the user's Web browser. You create the tags for XTP using either StyleScript or XSL.

To demonstrate how to use XTP, let's start with the basic design for a Web page written in HTML:

 <HTML> <BODY> Current User Count: </BODY> </HTML>

In this Web page, we just want to display the current number of users on our site at any given time. The Web developer has placed the user count in an application variable called usercount. So, we could just change the HTML to JSP (using XML tags):

 <HTML> <BODY> Current User Count: <jsp:expression>   application.attribute.usercount <jsp:expression> </BODY> </HTML>

Of course, if the developer needs to change the variable name, decides to place the count in another value, or changes how the value is obtained, we have to modify the JSP page. In our example, this isn't much of a problem, but if there are HTML tags for the look and feel of the page throughout, problems could result. The solution is to convert the HTML to an XTP page. The new code might look like this:

 <?xml-stylesheet href='usercount.xsl'?> <HTML> <BODY> Current User Count: <usercount/> </BODY> </HTML>

In this example, we replaced the static JSP code with a new tag called <usercount/>. Obviously there are no tags in the HTML specification with this name, so we must have another way of defining it. The definition of <usercount/> is found in a file called count.xsl, shown here:

 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output disable-output-escaping='true'/> <xsl:template match='*|@*'>   <xsl:copy>     <xsl:apply-templates select='node()|@*'/>   </xsl:copy> </xsl:template> <xsl:template match='usercount'>   <jsp:scriptlet>     Integer usercount;     usercount = (Integer) application.getAttribute("usercount");     if (usercount == null)       usercount = new Integer(1);     out.println(usercount);   </jsp:scriptlet> </xsl:template>

The count.xsl file contains either Extensible Stylesheet Language (XSL) or StyleScript definitions. In our example, we are using XSL to match against the information found in the XTP page listed earlier. There are two groups of matching code: the first copies the input to the output with any changes, and the second matches on "usercount" and performs some operation. Let's look at each of the groups individually.

First we have the code that pulls in tags or text from the input file and transfers them to the output without any changes. Although this code group appears first in the file, the match occurs only if no other <xsl:template match=""> statements are executed. The *|@* tells the server to match any text and any attributes of existing tags.

The second group uses a match against the text string "usercount". If a tag is found in the input text and it has a value of usercount, the code within the <xsl:template> tag executes. When you're using the <xsl:template>, any text that you place within the tags will be copied to the output file. In this case, we output JSP XML tags, which themselves include Java code to execute.

Recall from our discussion on the XTP to JSP to HTML process that the XTP page will be converted to a JSP page. This means that all of the JSP code we put into the output will eventually be executed by the system.

The XSL file needs to be placed in a directory where the system can find it when the server pulls the XTP page. In our case, we added an xml-stylesheet tag to the XTP page to tell it which XSL file to use. You must place the XSL file in the WEB-INF/xsl directory or WEB-INF/classes. If no xml-stylesheet tag is found in the XTP page, the system attempts to look for a default.xsl file in these locations:

The directory of the XTP file
The application root
WEB-INF/xsl
The Java classpath

With our XTP and XSL files, we have a directory structure that looks like the following (assuming we placed them in an application directory called users):

 /doc/users/users.xtp /doc/users/WEB-INF/xsl/usercount.xsl

The code is executed by browsing to this URL:

http://localhost:8080/users/users.xtp

The result is text showing the total number of users on the system—in this case, just one. With JSP 2.0 and JSTL, we have to replace the Current User Count: <usercount/> tag with Current User Count: ${usercount)