Generate Web Output in Multiple Formats and Languages with StrutsCX

s an open source add-on for the Apache Jakarta Struts Framework (or Struts), StrutsCX has its roots in a pure XML- and XSLT-based, multi-language and multi-layout project. With StrutsCX you can easily generate different output formats like HTML, XML, or PDF using standardized XML and XSL technologies. Struts serves as the ideal server technology to perform these XSLT transformations.

StrutsCX also enables you to save and output content in different languages and encodings. Handling information in English, German, French, Spanish, and Italian?as well as in Chinese, Korean, Arabic, Russian, and any other language in the world?is simple with StrutsCX.

A Quick Struts Refresher
Struts encourages application architectures based on the Model 2 approach, a variation of the classic Model-View-Controller (MVC) design paradigm. The great thing about the MVC design pattern is the relative independence it allows between the Model, View, and Controller. Struts processes all incoming HttpServletRequests in one central point, the Controller, where the ActionServlet, the ActionMapping, and several Action classes are assembled. The ActionServlet dispatches all the incoming HttpServletRequests to one of the Action classes. The ActionMapping object, which you can control through the struts-config.xml file, informs the ActionServlet to which class it should dispatch.

Figure 1: Communication Steps Between the Struts Model, View, and Controller

Figure 1 illustrates the Controller’s function: mediating between the Client, the View, and the Model. Only the Controller knows about the Model and the View, it sits between them like a switch. Neither the Model nor the View know about each other. The consequent separation of Model, View and Controller is essential for the successful use of Struts.

Author’s Note: You should place all the controller logic your application needs inside the Action class. You can communicate with the other layers of your Web or J2EE application from there. Although you’re able to also keep business logic in your Controller, it’s a good practice to keep it out of there. Use the components of the Model for this practice, because they are where the actual handling of your data takes place. Saving your data in a database should be a practice that’s part of the Model, too.

Once the Controller is done with a HttpServletRequest, it forwards it to the View. The View’s only job is the graphical presentation of data, for which Struts generally uses JavaServer Pages (JSP) inside the View.

In Struts, all communication between the Controller and the View takes place indirectly via the HttpServletRequest, HttpSession, and the ServletContext, and no technique is better suited to handle these then servlets. Struts categorically forwards the HttpServletRequest to a servlet. The Servlet Container automatically transforms JSP into servlets as well.

The Limits of Struts and JSP
Struts is expressly open to other View technologies besides JSP. So using alternative techniques for the Struts View starts with thinking about how to replace JSP with other servlet technologies, such as XSLT or an XSLT transformation managed by a servlet.

Figure 2 outlines the use of JSP within the Struts framework. The view is made out of JSP Custom Tag Libraries and the JSP, which use the Tags themselves. The ActionForm classes are JavaBean-like ValueObjects with setter and getter methods. They save the client’s state. In the Struts MVC concept, the ActionForms are located somewhere between the View and the Controller. Struts offers a whole set of specialized Tags you can use to access data in the ActionForms from inside your JSP.

Figure 2: The Struts Architecture

JSP facilitate Java Web programming very well. Together with the Tag Libraries, they provide a wide range of robust tools for the development of the presentation layer in Web or J2EE applications. However, JSP have some drawbacks:

Accomplishing a pipeline for the View is more complex. Separation of Layout and Style is not as natural as it is when using XSLT.How XSLT Fits In
XSLT is an official W3C standard for a flexible and powerful language that transforms the structure of XML data into text, PDF, HTML/XHTML, WML, VoiceXML, or any other XML format. An XSLT processor like Xalan or Saxon actually performs the transformation by using an XSL Stylesheet, which itself is an XML document (see Figure 3).

You define rules for the transformation of your XML data inside the XSL Stylesheet. The XSLT processor uses these rules during transformation. You also can use XPath expressions inside your XSL Stylesheet to select parts of your XML document in a compact manner.

Figure 3: Principle of XSLT Transformation

The basic concept behind XSLT/XPath is to separate XML data from its presentation. The same data can easily be presented in different forms and formats to suit different output devices. All the while, the input XML document stays unchanged. For each additional output format you just define another XSL Stylesheet. For a Struts application, this means you can:

Of course you can generate your XML document in memory; it’s not necessary to work with physical files. You can create the XML document as a Java object and hand it directly to the XSLT processor, which enhances performance incredibly.

StrutsCX: Struts with XSLT
StrutsCX combines the elegance of Struts with the power of XSLT. StrutsCX replaces the JSP of the View with XSLT while leaving the Controller and the Model part of Struts untouched.

Figure 4 illustrates the differences between Struts and StrutsCX. In the View, StrutsCX does not forward to a JavaServer Page but to a servlet, which organizes the construction of an XML-Output-Document object as well as the transformation of this object with an XSL Stylesheet. If an ActionForm Bean is present, the Action copies it to the HttpServletRequest, which is also added to the XML-Output-Document. Similar to Struts, the job of the StrutsCX Action is to mediate between the presentation tier and the other tiers of the Web or J2EE architecture, the business and integrations tiers.

Figure 4: The StrutsCX Architecture

StrutsCX behaves differently than Struts in the following aspects:

Despite their differences, you can use StrutsCX in parallel with your existing Struts application. StrutsCX merely abandons some of the standard Struts features and replaces them with XML, XSLT, and XPath. The StrutsCXServlet
As Figure 5 shows, in StrutsCX, the XSLT transformation process is organized through the StrutsCXServlet and its helper classes, StrutsCXDocumentBuilder and StrutsCXTransformer. The StrutsCXServlet controls transformations by:

1. Creating an XML document with the help of the StrutsCXDocumentBuilder
2. Forwarding this document to the StrutsCXTransformer for transformation purposes

Figure 5: The StrutsCXServlet

The StrutsCXDocumentBuilder gets the information it needs to generate the XML-Output-Document through the HttpServletRequest, the HttpSession, and the ServletContext. All of these are handed over to the one and only public method, createDocument(). The Struts Action checks for the wanted information in the HttpServletRequest, the HttpSession, or the ServletContext, depending on which is best suited to keep the information. The virtual XML-Output-Document that the StrutsCXDocumentBuilder creates contains the following information:

To create the XML-Output-Document use JDOM.

In StrutsCX, the values of each dataset can be presented to the StrutsCXServlet as an XML object or as a JavaBean. If you choose the latter, you need to add one or more JavaBeans to an ArrayList object, which is then passed to the StrutsCXDocumentBuilder via the HttpServletRequest. The StrutsCXDocumentBuilder uses its helper class StrutsCXBeanToElement to automatically create XML Elements out of the JavaBean’s data and add it to the XML-Output-Document (see Figure 6).

Figure 6: The XML-Output-Document

This helper class is based loosely on its archetype, Model 2X, a project quite similar to StrutsCX that Julien Mercay and Gilbert Bouzeid developed. It analyzes the content of each JavaBean with the help of the Java Reflection API and the Java BeanInfo interface. It generates the XML Element out of the name and value of the JavaBean setter and getter methods.

In much the same way, StrutsCX serializes data out of the ActionForm object with its setters and getters, the HttpServletRequest, the HttpSession, as well as the ActionErrors object with its error messages. I’ll discuss the StrutsCX error handling a little later.

The StrutsCX-Resources-Properties are XML files that are analogous to the Struts ApplicationResourses.properties. You should provide one for each language in which you want to present your application. It should contain all the internationalized text strings you need in your presentation, besides the data of the integration tier. Other than the ActionForm and the ActionErrors, the StrutsCX-Resources-Properties should not be transferred to the StrutsCXServlet via the HttpServletRequest. Instead, use the ServletContext just once at the start of the Servlet Container, right after the first call of one of the Action classes. This ensures better performance.

The StrutsCXTransformer does the actual XSL transformation. This class encapsulates the whole transformation process by using JAXP, the Java API for XML Parsing?which is incredibly cool because it abstracts from the de facto XSLT processor you use. Of course you have to provide a proper XSL Stylesheet too, which should likewise be selected by the Action class and added to the HttpServletRequest. The StrutsCXTransformer reads and parses this XSL Stylesheet just in case it was changed since the last call. It uses its helper class StrutsCXURIResolver, which automatically converts relative URIs into absolute URIs.

The StrutsCXTransformer also offers some practical goodies to make your life easier. For instance, if you’d like to send the XML-Output-Document directly to the HttpServletResponse, add the following parameter to the HttpServletRequest:

debugxml=true

This feature is very convenient for the development of XSL Stylesheets and looks great in the newest versions of Internet Explorer and Netscape/Mozilla, in which you can open and close whole XML Element sets.

If you’d like to disburden your Web server and have the client do the XSLT transformation, you can set another parameter to the HttpServletRequest:

xsl_clientside=true

The StrutsCXDocumentBuilder adds a Processing Instruction to the XML-Output-Document with a pointer to the location of your XSL Stylesheet. This document is sent directly to the client’s browser. No server-side transformation takes place.

As mentioned before, StrutsCX rejects the Java Resource Bundle technique and uses the StrutsCX-Resource-Properties, simple XML files to save text strings for internationalized Web applications. Similar to Struts, StrutsCX can select the appropriate file during runtime by checking the java.lang.Locale object. StrutsCX-Resource-Properties result in quite a lot advantages for you:

      ...    Tag    ...    ...

Figure 7: Simple Editing of the StrutsCX Resources-Properties

Note that the StrutsCX-Resources-Properties should be read into the ServletContext as an org.jdom.Document object the first time one of your Action classes is called. StrutsCX learns where to find them from the strutscx-config.xml, the special StrutsCX configuration file. Therefore inside the web.xml, the initialization parameter to read in the Resource Bundles is obsolete. Error Handling with StrutsCX
StrutsCX controls the validation of input errors exclusively inside the Action class. The settings in the ActionMapping conform more or less with the ones in Struts. Inside the ActionForm object, nothing really changes. If errors occur, the validate() method returns an ActionErrors container filled with ActionError objects. However, the method add() of the ActionErrors object does need a Struts ActionMessage object (see Figure 8). Although StrutsCX does not use this object, it is added:

// code-snipped of Struts FormBean:public ActionErrors validate(    ActionMapping mapping,     HttpServletRequest request) {  ActionErrors errors = new ActionErrors();  if (title == null || title.length() < 1) {    errors.add("title", // name of input field    new ActionError("anything")); // anything  }  return errors;}

Figure 8: The Examination of the ActionErrors Container

By calling the validate() method of the ActionForm object, the Action class gets hold of the ActionErrors container with its ActionError objects:

// code-snipped of Struts Action:ActionErrors errors =     actionForm.validate(mapping, request);

If it’s filled, the ActionErrors container will be added to the HttpServletRequest and forwarded to the ERROR target defined inside the struts-config.xml. If the ActionErrors container is empty, the HttpServletRequest gets forwarded to the SUCCESS target defined inside the struts-config.xml:

// Action code continued:if (!errors.empty()) {  request.setAttribute("errors", errors);  forward = "ERROR";} else {  forward = "SUCCESS";}

Of course, additional ActionError objects can be added to the ActionErrors container inside the Action classes. There is no restriction to the validation of user input. During XSLT transformation, all these error objects become incorporated into the XML-Output-Document so they can be used by the XSL Stylesheet. Here’s an extract from of an XML-Output-Document:

  ...    ...                    ...        ...    ...