When developing Web applications that use Java and XML there are many options, including (among others) the Apache Struts framework and the Extensible Stylesheet Language Transformation (XSLT) language.

At first blush, these options may seem like an "either/or" proposition, considering the fact that the view portion of Struts serves essentially the same purpose as XSLT: to render the view, or visual output, of the application. This article will show how XSLT can be used within the view layer of Struts to leverage the strengths of both and allow you maximum flexibility in the visual presentation of your Java Web applications.

Some of you may be thinking design patterns at this point. That is, Struts uses the model 2 (M2) design pattern, which began as the model-view-controller pattern (see Design Patterns: Elements of Reusable Object-Oriented Software from Addison Wesley). The M2 pattern has been extended by incorporating XSLT (for XML applications), creating the model 2X (M2X) pattern, which is very close to what I'm about to show you. However, I've taken yet another deviation, which I believe adds a greater level of flexibility and robustness.

For the sake of brevity I'm assuming at least introductory knowledge of both XSLT and Struts. I'm also assuming some basic knowledge of the Cascading Stylesheet (CSS) language, because what good would a flexible view layer be without an externalized look-and-feel? I will provide a brief overview of both Struts and XSLT, but those overviews will be neither extensive nor adequate to fully understand the contents of this article.

Overview
One of Stephen R. Covey's Seven Habits of Highly Effective People (Simon & Schuster, 1990) is to "begin with the end in mind." In keeping with Mr. Covey's habit, allow me to show you what we're trying to accomplish. After I show you the end, I'll put everything together piece by piece, to (hopefully) solidify these concepts.

Figure 1 shows each part of the application, highlighting the Struts and XSLT parts.

Taking a step back from Figure 1, Figure 2 shows which parts of Figure 1 belong to model, view, and controller, respectively.

What I've added to Struts is a generic view bean, which uses XSLT to transform XML into the view output (e.g., XHTML). For any given view to be rendered, any XML and any XSL stylesheet can be used together to generate the output. The rationale behind this usage, with Web pages in particular, comes from the observation that many (if not most) display (as opposed to input) Web pages are similar in nature.

Generally speaking, Web applications have a kind of template for visually appealing aspects such as a navigation and/or status bar (with and/or without graphics). Within this template, there are usually one or more sections that contain important data; that is, business data within HTML. Take Figure 3, for example.

The banner and navigation portions of Figure 3, along with the look-and-feel defined by the colors and fonts, make up the template I mentioned earlier. Within this template, there is a listing of persons, ordered by last name. This listing constitutes the dynamic, or business, data, which (in this case) is represented within an XHTML table.

If using Struts alone, this same output could be generated, there's no doubt about that. However, more Struts tags would be required, and they could become cumbersome (HTML tables and Struts tags are a bit frustrating sometimes). Furthermore, performing XPath operations such as selecting certain nodes in the set, or XSLT functions such as sorting, is not nearly as simple using Java as XPath and XSLT. If that's not enough to convince you, consider XSLT (the stylesheet language) as a language that is specialized for turning XML into something else, such as XHTML. (Java isn't specialized in this way, so Struts isn't specialized in this way either.)

Within the pattern I'm describing, the data portion of the page is presented using XSLT, because XSLT is great at taking XML data and transforming it into XHTML (and in this case, sorting by last name). The rest of the visual presentation is plain XHTML, which is created as a JSP. Using this pattern leverages the programming robustness of XSLT while at the same time allowing the graphic design team to use a JSP, which can be designed with a GUI tool. In other words, this framework allows programmers and graphics/Web design folks to do what they do best.

Struts
Apache Struts is an open-source Java/JSP Web application framework available as part of the Apache Software Foundation's Jakarta project. Struts provides many of the parts (or beginnings of the parts) shown in Figures 1 and 2. Specifically, Struts provides the ActionServlet, ActionForm (which is subclassed), and DynaActionForm (with Struts 1.1) classes. These classes understand how to take HTML form data and pass it along to the necessary classes in order to enable business processing, which is contained within a subclass of Struts' Action class. Your subclass of Action performs the necessary business processing and forwards the reply to a JSP along with a Java bean containing the response data. This response data is displayed within the JSP using special Struts JSP tags. Struts understands how to go from page to page by utilizing a Struts-specific XML file, named struts.config.xml, which is read by the ActionServlet (see Figure 1).

But that's not all Struts provides. It also has robust error handling, and something called "Tiles" (Struts 1.1, the same basic concept is called "templates" in 1.0x), which enable you to break down a page into sections (a lot like I did in Figure 3) and use different Struts interactions (e.g., Actions) to paint each section in a reusable fashion. However, for simplicity I've left most of the error handling and all of the Tiles out of the example I'm going to present.

Without Struts, you'd most likely create something very similar - I've done so before Struts came along, and have seen at least one other person I know do the same. That's one of the reasons Struts is so popular; it provides a framework to do what you'd likely do anyway when creating a Web application. Of course, another reason Struts is so popular is that it's free, including source code.

XSLT
XSLT is a World Wide Web Consortium (W3C) recommendation that is intended to provide a way to transform XML into another form. The most common form is XML transformations (with XML to XHTML being an example of this form). The W3C's recommendation has been implemented by several companies/organizations, including Microsoft (XSLT is built into Internet Explorer version 4 and higher), and the Apache Software Foundation's Xalan project, which I'll be using for the example presented shortly.

XSL transformations consist of four basic parts: an XML source document, an XSL stylesheet (which is an XML document itself), an XSL processor, and a destination document. The XML source document and XSL stylesheet are read by the processor, which then performs the transformation producing the destination document (I deliberately didn't use the term "destination XML document" because technically, XSLT can transform XML into any other textual representation).

The most important part of XSLT, from the visual programmer's perspective, is the XSL stylesheet. The stylesheet contains the code that tells the processor how to transform the source to the destination. This XSL code uses templates, which catch desired XML from the source, and performs processing on it. How it does so is a "simple" matter of details, which are outside the scope of this document. If you're new to XSLT, there are many excellent resources on the Web that can assist you as you learn XSLT.

XSLT is a very robust language that can transform XML into anything ranging from HTML to plain text. Having a firm grasp of XSLT is a must for any XML programmer. Within this article, I use XSLT to leverage its strong XML-to-HTML characteristics, while doing so within Struts, which has strong Web application framework characteristics.

Sample Application
Enough of this over-arching generic stuff! It's time for me to move on to the sample. The sample application that follows is a basic user registry, which contains a simple HTML form page and a single output page. The data is stored within an XML file that is updated whenever a new user is added. In other words, the input page provides data that gets inserted into the proper place within an XML file that is displayed after the update.

The HTML input page
The easiest portion of the sample to create is the HTML input page. I could have created the input page as a JSP, but for simplicity I've elected to create it using plain HTML. To externalize the look-and-feel of the application (e.g., colors, font face), I used an external cascading stylesheet file (named lookandfeel.css) that has entries similar to the following snippet.

BODY
{
BACKGROUND-COLOR: #d7a8a9;
COLOR: #333366;
FONT-FAMILY: 'Default Sans-Serif'
}

This snippet sets key look-and-feel elements for the HTML BODY tag, including basic color and font settings. Similar entries exist for other tags (e.g., H1, H2, and TD), which, when taken as a whole, define the entire look-and-feel for the Web application. The best part of using this stylesheet is that if I want the look-and-feel to change for every page that uses the CSS, I only have to change the stylesheet, not the pages that use it (such functionality is a basic benefit of externalizing a stylesheet). Perhaps I don't need to state that the CSS is entirely different from the XSL stylesheet, but I'll mention it just to be safe.

Figure 4 shows what the inputPage.html file looks like when rendered within a Web browser.

The Struts ActionForm and Action subclasses
Obviously, some code has to handle the HTML form, and this is where the first Struts parts come into the application. To retrieve and store the HTML form data, I created a Java class named InputPageForm, which extends the Struts ActionForm class. Struts semi-automatically maps the HTML form data with the data in the Java class. I created three private class variables in the class, which correspond to the three HTML form input elements, and named them the same as the "name" values in the HTML form.

private String firstName = null;
private String lastName = null;
private String dob = null;

I then added getters and setters for the variables. Struts takes care of the rest at runtime (by using the struts-config.xml mapping, which I'll show shortly).

After creating the ActionForm, I created an Action class (a subclass of the Struts Action class), named InputActionAction, which performs the business logic. At the heart of the Action class is the execute() method, where processing starts.

In the case of this sample, the Action class's execute() method first uses a Struts utility class known as PropertyUtils to retrieve the data from the ActionForm without actually knowing the Java type explicitly (Struts knows the actual type because it's defined within strut-config.xml). That code is simple, and is shown in the snippet below.

// Get form values
String lastName =
(String)PropertyUtils.getSimpleProperty(form, "lastName");
String firstName =
(String)PropertyUtils.getSimpleProperty(form, "firstName");
String dob = (String)PropertyUtils.getSimpleProperty(form, "DOB");

The form object, the first parameter to the getSimpleProperty() method, is passed by Struts into the execute() method of the Action class automatically. At this point, I added an entry within struts-config.xml, which maps the form to the proper Java class.

<form-beans>
<form-bean name="inputPageForm">
type="com.neuggsville.forms.InputPageForm">
</form-bean>
</form-beans>

After the data has been retrieved, the Action class retrieves the contents of an XML file (named "users.xml"), then uses the Apache Xerces package to modify the XML within a method called createNewUser(). The createNewUser() method adds the new user in the appropriate location, using the data from the ActionForm class, then saves the XML document. Obviously, your business logic and persistence mechanism are likely to be vastly different from my simple example. However, the structure would remain essentially the same. Listing 1 shows the contents of users.xml.

The view bean, XSL stylesheet, and output JSP
At this point I set my InputActionAction class aside so I could create the view bean, XSL stylesheet, and output JSP. I'll return to the InputActionAction class after the output view artifacts have been created.

The view bean, named XSLTOutputBean, does not inherit from any Struts class, and recall from Figure 1 that this view bean has been XSLT enabled. The class itself is very simple in that it has only three data members, as shown in the code snippet below.

private String theXML;
private String theXSL;
private String theResult;

The XML and XSL Strings represent paths to the XML and XSL documents, respectively (these values are set within the Action class, as I'll demonstrate before too long). The result String is the actual result of the XSLT transformation, and is represented as XHTML. The main processing of this class happens within the getTheResult() method, which is more than a simple getter method to retrieve the "theResult" data element. The method uses classes from the Xalan package to perform an XSL transformation on the XML using the given XSL stylesheet. See Listing 2 to see the entire contents of the getTheResult() method.

Speaking of the XSL stylesheet, I could have created the stylesheet the moment the XML data and final output HTML screen were defined. Thinking about the order of events in larger projects, being able to have a sample of the end data early on allows graphic and front-end programmers (e.g., XSL stylesheet writers) the opportunity to develop the entire front end in tandem with the Action class. Such parallel development is crucial to the success of large projects and a real advantage to using XSLT and Struts in this way.

Programmatically speaking, the XSL stylesheet (named usersOutput.xsl) is quite simple. It has two templates, one to match the root "Users" element and another to match the "User" element child (or children) nodes.

The "Users" template creates the XHTML table structure, then calls the "User" template, "passing" (not in the Java sense, but in the XSL sense) it the "User" nodes, sorted by "LastName." Listing 3 shows the "Users" template.

Most of this listing is just XHTML, which creates a simple table. However, the XSL processor will only run this code when a "Users" element is caught in the source XML document. Then, after creating an HTML header, the XSL element <xsl:apply-templates select="User"> "selects" (this is an XPath expression) each "User" element under a particular "Users" element, for processing by a "User" template (which also appears in the stylesheet). Then, prior to deferring to the "User" template, the <xsl:sort> element performs a simple sort by the "LastName" element.

The "User" template simply outputs each child of the "User" node (i.e., "LastName", "FirstName", and "DOB") as columns in the HTML table. The contents of this template are contained below.

<xsl:template match="User">
<TR>
<TD><xsl:value-of select="LastName"/></TD>
<TD><xsl:value-of select="FirstName"/></TD>
<TD><xsl:value-of select="DOB"/></TD>
</TR>
</xsl:template>

This simple code outputs the value of the LastName, FirstName, and DOB elements as rows in an XHTML table.

Recall that the result of the XSLT is going to be placed within the context of a larger XHTML document, which is defined within the output JSP. That JSP uses the XSLTOutputBean's getTheResult() method to paint the XHTML table labeled "Data (dynamic)" in Figure 3. The output JSP, named userOutput.jsp, is mostly plain XHTML (the template I mentioned earlier), with a very small Struts tag, which gets the result from the XSLTOutputBean.

<bean:write
name="theBean"
property="theResult"
filter="false"
/>

The <bean> JSP tag is provided by Struts and identifies the servlet session variable (i.e., "theBean") and data element (i.e., "theResult") to use when executing the JSP. Again, such coding would have to be done without Struts, and it wouldn't be as clean and concise, unless you built your own Struts-like framework.

To maintain the same look-and-feel, I used the same CSS file within this JSP.

Finishing up the Action subclass
At this point, I have two options. I can edit the struts-config.xml file, creating the mapping to the Action and JSP forward, or I can continue coding the InputActionAction class. I'm going to finish the Java coding before editing the struts-config.xml file, for no particular reason.

The only things left to do with the Action class are to instantiate the view bean and forward the result to the JSP. The names of the XML document and XSL stylesheet are contained within an externalized property resource bundle (named ApplicationResources.properties). The files are retrieved using HTTP paths, but you have the option to implement the retrieval in a number of different ways (see the Apache Xalan StreamSource class to learn about your options).

After the view bean has been instantiated and initialized, a Struts class named ActionMapping is used to forward processing to the view JSP through a mapping that exists within the struts-config.xml file that maps a simple String ("output") to the actual JSP (you'll see this mapping in the next section).

At this point, all of the development artifacts are complete. Next, it's time to play connect the dots using the struts-config.xml file.

Creating the flow using struts-config.xml
The mappings for the Action class and JSP forward are contained within the struts-config.xml file. The mappings are used by the ActionServlet to point processing in the right direction at runtime. As an XML file, the flow then becomes external to the application (a highlight of using Struts). Listing 4 contains those mappings.

For those of you familiar with Struts, you'll notice that I made some simplifying compromises to my sample application. I didn't use Struts validation, internationalization, or extensive error-handling capabilities. I also didn't leverage the Struts 1.1 DynaActionForm, which allows for the definition of the HTML form within struts-config.xml. Again, I made these compromises for the sake of simplicity, not because such functionality isn't entirely useful (it is!).

Some Words of Caution
It's important to note that although using XML and XSLT in the way I described within this article is very robust and flexible, this solution isn't right for every problem. First off, not all Web applications use XML as a messaging mechanism (and some necessarily shouldn't use XML). Second, and perhaps more important, even if XML is the messaging mechanism, XSLT may not scale well if the XML source document(s) are arbitrarily large and a document object model (DOM) is used as in the example. In situations where the source XML may be very large, be sure to perform thorough performance and scalability testing on your application (as early on as possible, just in case it doesn't scale or perform).

Conclusion
If you run the application and enter data in the HTML form (Figure 4), you'll get a result that looks like Figure 3. In a traditional application, there are many interactions, some of which accept HTML form data, some of which display data. In the case of display pages in particular, using XSLT within the Struts framework allows you to not only leverage the right tool for the job (XSLT for display of XML data, Struts for application framework services), but allows for the right persons for those jobs as well. I hope you find this Struts/XSLT pattern useful, if not "as-is," then as some derivation.

Acknowledgement
Special thanks to my good friend Richard Glatz, a talented graphic artist who created Figures 1 and 2 along with the banner graphic for Figure 3. Working with Rick has shown me how critical the relationship between artists and programmers is, and that great Web sites require both talents in equal measure.

Resources

Apache Xerces: http://xml.apache.org/xerces2-j/index.html

Published Mar. 28, 2003— Reads 15,185 — Feedback 7
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Figure 1

▪ Figure 2

▪ Figure 3

▪ Figure 4

▪ Source Code

About Frank Neugebauer
Frank Neugebauer is a consultant with the Insurance Solutions Group of IBM Global Services. He has been using Java since 1996 and has worked on the architecture and implementation of enterprise Java solutions using Servlets, EJBs, XML, and XSLT. He has also taught Java, HTML, and JavaScript at the University of Michigan Center for Corporate and Professional Development.