Where to Point Your View — JSP or XSL

Introduction

The MVC (Model View Controller) pattern is a common approach for architecting the presentation tier of your Web application. This article explores options for implementing the view or “V” in MVC. JSP (Java Server Pages) and XSL (eXtensible Stylesheet Language) alternatives will be considered. Both of these approaches are based upon industry standards and are supported by open source implementations.

In our exploration of how to implement the view, we’ll cover the following topics:

• A Review of MVC
• The JSP Approach
• The XSL Approach
• Commonalities
• Differences
• Comparison Matrix
• Which Option Is Best for Your Next Project?
• Summary

The article assumes a basic understanding of JSP and XSL technology. There are additional resources at the end for further detail about Java Server Pages, eXtensible Stylesheet Language, and the Model View Controller pattern.

A Review of MVC

The MVC architecture decouples the code to handle user actions (Controller), the data and business logic (Model), and the presentation (View). Let’s look at a typical transaction to better understand the responsibilities of the Controller, Model, and View objects. Then we’ll be better positioned to see how those responsibilities can be implemented when a JSP or XSL view is used.

A client initiates a request, say, for example, to view his bank account balance. The controller object receives this request, and instantiates a model object. The model object accesses a persistent store such as a relational database to retrieve the bank account. Next, the controller asks the view object to display the model and return it back to the client.

The JSP Approach

When the view is implemented as a Java Server Page, the controller object, often but not always a servlet, forwards processing of the request and the response to a JSP view. Prior to this, the controller will add a reference to the model object to the user’s session or request object. The JSP will get a handle on the model object, and then will construct the HTML or WML markup to be returned to the client.

The XSL Approach

When the view is implemented in XSL, the basic flow of the transaction remains the same. However, the model now needs to be represented in XML format. Once the model has been built, the controller asks a stylesheet to transform the XML into the desired HTML or WML output.

Note that an XSL view could be implemented on the client rather than the server. In this case, the controller would return the XML to the client where it would be rendered by the XSL stylesheet. However, varying browser support for XSL makes this a bit risky at this point in time.

What Do the Approaches Have in Common?

Separation

Both the JSP and XSL approaches clearly separate presentation from business logic, data, and user actions because these advantages are inherent in MVC. This makes maintenance easier. It also allows for focused developer roles and parallel development that helps larger projects to scale better.

Industry standards

Both approaches are also based upon industry standard technology. This means that you will be able to find developers to maintain the system, and you will have vendors competing to supply the tools and platform to build and run your application. There are also many open source tools and platforms as well. There are plenty of books and training available in both technologies.

Tool support

Both approaches have tool support to aid the development process. JSP Tag library support is beginning to show up in third-party tools that allow you to graphically build the markup. XML IDEs speed the development of the XSL.

What Differentiates the Approaches?

Parallel development

I find that XSL makes parallel development easier. Once the XML data format has been agreed upon, a presentation developer can completely build the XSL view markup through an XML IDE without even needing a servlet container to construct and test the code. A XSL developer does not have to know Java. It is very easy to integrate the view with the rest of the application when ready. With a JSP view, this could still be accomplished by creating a “stub” object to stand in for the model, but it doesn’t lend itself as naturally to this approach.

XML

If your data is already in XML format (which it often is), it isn’t necessary to parse the XML and transform it into objects. The XML can be transformed directly by the XSL view. When a result set is a complex tree structure, it may result in many value object classes often built for the sole purpose of communicating the data to a JSP view. This can be a time-consuming task and creates many temporary objects to be garbage collected.

Modular code

In a XSL stylesheet, it is possible to modularize the routines (called templates) for creating your markup language and make your routines rule based. I find that it is much easier to maintain than a JSP. It is still possible to build your markup in a procedural fashion and care should be taken in making the stylesheet as maintainable as possible.

It is possible to write your entire application, not just the view, in a JSP. The developer must be very conscious of the responsibilities of the view and not cross over into the responsibilities of the controller or model, for that matter. XSL, on the other hand, is pure presentation and forces decoupling of presentation and data.

.NET

One interesting difference between the two approaches is that XSL code and the skill for crafting stylesheets is portable between the .NET and J2EE platforms. The same couldn’t be said for JSP. I would think that there will be more third-party tool support for XSL since there is a broader developer audience, but we’ll have to see how this plays out.

Performance

Even though you can potentially create fewer value objects, XSL will perform slower than JSP. However, the Java Transformation API for XML (TrAX) allows stylesheets to be compiled, dramatically improving performance.

Comparision Matrix

The following table summarizes the above discussion on what the approaches have in common, and what differentiates them.

Which Option Is Best for Your Project?

With the preceding comparison matrix in mind, let’s look at some scenarios that would lead you to choose JSP or XSL for your next project.

From the above discussion, you might see a strong leaning toward using XSL for implementing your view. This hasn’t been the industry standard approach, although XSL is an industry standard technology. It’s newer than JSP. It’s not as optimized yet. But it more naturally fills the responsibilities of the View.

Favor XSL

Let’s look at reasons why you should favor implementing your view in XSL over JSP:

• From an architectural perspective, XSL fills the responsibilities of the View and nothing more. It’s pure presentation. With a JSP, there is always the danger of overstepping the boundaries.
• If your application is dealing with XML data, then XSL is the easiest and most straightforward way to parse and transform the XML into other formats.

Favor JSP

Let’s look at some reasons why you might favor implementing your view in JSP over XSL:

• You have a significant investment in include files, beans, tag libraries, and frameworks to support JSP. Going to XSL might be a big leap because these investments would need to be ported to XSL. In this case, you may stay with JSP, or you may consider some of the following hybrid options.
• Extremely high performance is needed for the application.

Hybrid approach

It is not always desirable to adopt a pure JSP or a pure XSL solution. Here are a few examples of how both technologies can be used to help render the View:

• A JSP is used to create XML from objects. The XML in turn is rendered into HTML or WML by a XSL stylesheet.
• A JSP uses XSL as a “helper” and includes the output from a stylesheet into the HTML or WML stream it is creating.
• A JSP is used to build a data capture form, but the XML results are displayed using XSL.
• A XSL stylesheet is used as a code generator to dynamically create a JSP.
• A JSP is used as a code generator to generate an XSL stylesheet.

Summary

Given that MVC is the way to build a J2EE application, how do you implement the “View” or V in MVC? Many would answer, “Well, a JSP, of course” since this is an industry best practice. However, this isn’t the only standards-based approach. XSL is gaining maturity and acceptance and should also be considered for this task.

Additional Resources

JSP resources

The definitive source of information about Java Server Pages technology can be found at http://java.sun.com/products/jsp/.

XSL resources

An excellent tutorial and links to other XSL resources can be found at http://www.w3schools.com/xsl/default.asp.

Information on the Java Transformation API for XML can be found at
http://xml.apache.org/xalan-j/trax.html.

MVC resources

Check out the following link to study more about MVC:

http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/

About the Author

Jeff Ryan is an architect for Hartford Financial Services. He has eighteen years of experience in information technology in architecting and developing automated solutions to business problems. He may be reached at jryan@thehartford.com.