Most of the popular view technologies for web applications today are for some reason centered around HTML. That seems like a crazy statement, since one might say that web applications should be tightly coupled to HTML-based views since HTML is what is supported by the browser. But web applications today are so much more than just being supported and rendered in a browser. They are about streaming information on the web into a view technology, be it the browser, wireless devices, desktop clients, etc… to render a usable representation of that data for the consumer (note: consumer is not meant here in a marketing sense).
Though most MVC frameworks today provide some support to render non-HTML views, most are still tightly coupled to HTML and if you want to go outside of that norm, it becomes more difficult with less and less reasons for using the framework in the first place. You also might loose some abstraction from various APIs (servlet request/response, etc…) that these frameworks are so good at providing.
XSLT views are a nice, lightweight approach of rendering views for presentation. It allows for flexible support of various view technologies and internationalization. With the popularity of Web 2.0/Ajax applications, you’d think it would only be natural to start embracing the client side browser XSLT facilities. Most popular browsers, IE, Firefox, Opera, and Safari provide such functionality. IE and Firefox has the most robust XSLT facility, with Opera and Safari catching up.
Here are some benefits and features:
- XSL transformations are fast. In some instances faster than downloading large HTML pages.
- XML can be transformed to different formats HTML, WML, etc… depending on the client requesting it, by just appending the correct stylesheet. It can even be transformed to different HTML DOMs for different browsers, though you can better control browser rendering/support.
- XSLT processing pipelines can be used to transform to various intermediary formats in a pipeline.
- Ajax is a natural way of working with XML on the client and allows asynchronous loading of XML data, which can later be transformed on the fly with various stylesheets.
All of these points were valid at some point, but are quickly loosing credibility. First, you don’t have to move any logic to the client side, and even if you do, you can separate view logic from business logic and though only move a subset of the view logic to the client, if it makes performance sense. Second, browser incompatibility, though still an issue, is becoming less and less a roadblock, as the gap in feature support is closing and there are many frameworks available out there that provide cross-browser functionality (i.e. Google’s AJAXSLT).
Of course you don’t want to use XSLT views blindly in all applications. As with anything else, this would be a part of the design-time decision and would have to be evaluated. Here are some valid scenarios where you might want to consider using XSLT views.
- You’re persisting your data in XML. It only makes sense to stream it as it persists and transform to viewable formats either on the client and/or on the server.
- Your HTML pages are huge and it takes a long time to stream and render by the browser. You might consider just streaming the data in XML and having a cached client side XSLT stylesheet that will do the rest.
- Your server load needs to be reduced and though you want to utilize some of the client browser processing power. You can do client side transformation which will take away some of the load burden of processing and transforming the data for presentation on the server side.
- You need a more robust way of supporting multiple view technologies (i.e. HTML, WML, SVG, etc…). XSLT will allow you to have a standard data feed that’s transformed to multiple views on the fly by attaching an appropriate stylesheet.
- You need to support and render data retrieved from a web service and/or some other application. The data needs to be displayed in a consistent manner. You can employ an XSLT pipeline to first transform the incoming data to an application standard format that is understood by the final XSLT stylesheet. The final transformation can then render the data to the view technology.
There are more of these scenarios than I can think of right now, but even if your application’s requirement(s) fits one or more of the above, that does not automatically mean that XSLT views should be used. You should first evaluate the actual relevance of the above scenarios to your application (i.e. what percentage of the application will be effected by this functionality).
I hope that eventually component based frameworks like JSF, Shale and action based frameworks like Struts, Webwork (and others) will embrace the raw XML views with the ability to apply XSLT on the server and client transparently. I sort of like Spring MVC, which has a quite nice built in support for XSLT views and great flexibility over the amount of functionality you want to use, etc… Spring MVC allows you to use only the components of the MVC you need, without forcing you to delegate control over to the framework. Though it has multiple implementations for Controllers and Views that you can reuse and/or extend. A prime example of great OO design.