Where to Point Your View -- JSP or XSL, Page 2
What Do the Approaches Have in Common?
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.
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.
What Differentiates the Approaches?
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.
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.
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.
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.
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.
The following table summarizes the above discussion on what the approaches have in common, and what differentiates them.
|Attribute||JSP View Approach||XSL View Approach|
|Based on industry standards||Yes||Yes|
|Separate business logic and data from presentation||Yes; however, it is possible to cheat in your JSP||Yes|
|Modular Code||You can modularize with includes and tag libraries, but it is very procedural. The JSP gets compiled into a single (often huge) Java method.||Rule-based templates are very modular and easy to maintain. However, you can cheat and build your stylesheet in a very procedural fashion.|
|.NET Portable Skill and Code||No||Yes|
|Performance||Excellent||Generally acceptable. Can be optimized.|
|XML Model||Yes, but you need to parse the XML yourself||Very easy|
|Parallel Development||Yes, with some effort||Very easy|