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.