devxlogo

Generate Web Output in Multiple Formats and Languages with StrutsCX

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:

  • Programmers can put application logic inside their JSP. JSP should be used solely to display data graphically. Otherwise, programs can easily become complex and unmanageable.
  • JSP are not 100 percent XML compatible. JSP cannot guarantee that their output will be 100-percent, well-formed XML. In this new era of myriads of XML-consuming Internet access devices, this can be quite a problem.
  • During development, each change made to a JSP forces the Servlet Container to re-translate it into a servlet. With some servlet engines, this leads to annoying delays during development.
  • 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:

  • Represent all your data in the form of an XML document
  • Transform this document (with the help of an XSL Stylesheet) into any data format you like
  • 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:

  • In the View, StrutsCX uses XSLT instead of JSP.
  • Internationalization is not realized through the Java Resource Bundle technique but through a pure XML solution.
  • StrutsCX does not need any Tag Libraries to present error messages. It uses W3C standards like XML and XSLT/Xpath instead.
  • 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:

  • The data of the integration tier?this could be database data, data from Enterprise JavaBeans, or data directly out of flat XML files
  • An (optional) ActionForm Bean with the state of the client
  • An (optional) ActionErrors object with the Struts error messages
  • The StrutsCX-Resource-Properties, which under StrutsCX replace the Java Resource Bundles
  • The data of the HttpServletRequest
  • The data of the HttpSession
  • 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:

  • Besides using the Java Resource Bundle, you can check the consistency of your properties file by providing a DTD or an XML Schema.
  • Like always in XML, you can organize the content hierarchically:
          ...    Tag    ...    ...
  • Inside the XSL Stylesheets, you can easily gain access to these values by using W3C standard XSLT/XPath expression instead of a JSP-Tag:
  • XML uses UTF-8 as standard encoding and offers access to letters in all languages. The StrutsCX-Resources-Properties benefits from this.
  • The StrutsCX Resources-Properties can be filed outside the classpath. Like all the files you like to hide from direct access via HTTP, it’s best to put them somewhere inside the /WEB-INF folder.
  • Translators can use modern XML Editors to edit comfortably the content of the XML files (see Figure 7). There is no similar feature when editing the Java Resource Bundles.
  • In StrutsCX all configuration files are XML based. There is no mix of Java properties and XML properties like you have in Struts.
  • 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() 
    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:

      ...    ...              Please insert a title!      ...        ...    ...            ...    ...

    Inside the XSL-Stylesheet this information can be used to compose an appropriate error message:

      

    Coding the XSL Stylesheet is very similar to using a JSP Tag: the goal is to show the error message just in case the xsl:if statement is true, which means an error Element exists inside the XML-Output-Document (see Figure 9). An XPath Node Test does the validation. The text of the error message is part of the XML-Output-Document too, and this text automatically gets serialized into it with content from an appropriate StrutsCX-Resources-Properties file.

    Figure 9: Multi-language Error Messages with StrutsCX

    The Advantages of Doing It the StrutsCX Way
    Using XSLT in the Struts View has the following benefits:

  • The whole Web application gets rid of all the JSP and the Tag Libraries. Because lots of declarations can be skipped, the web.xml suddenly gets lithe and lissome.
  • You don't have to cram all these Tags. Instead, you deal with the XSLT and XPath standard, knowledge of which you can use outside the Java world.
  • You can't put business logic inside your XSL Stylesheets. Separation of data, application logic, and the graphical representation of data is part of the XSLT concept.
  • XSLT is open for all kinds of output formats: Text, HTML, and XML in all their flavors. There are no HTML-centric concepts like with JSP.
  • XSLT guarantees the output of 100 percent well-formed XML.No more waiting for your JSP to be transformed into servlets and compiled into the Servlet Container. The XSL Stylesheets can be used right out of the box.
  • With XSLT, it's easy to generate an output pipeline for the view by putting several transformations in a row. This way you can write sequential XSL Stylesheets and send your XML from one to another.
  • Separation of layout and style is possible using XSLT. By defining special layout templates, you can separate the biggest part of your HTML code from the XSL Stylesheets.
  • As this article has explained, you have plenty of reasons to try StrutsCX. You can begin by downloading the product and can even take a comprehensive sample application for a test drive (see the Sidebar: The StrutsCX Prototype).

    devx-admin

    Share the Post: