Solving XSLT client-side processing issues

You are already using XSLT as a template engine on the server. Now it’s time to transfer the xsl transformation to the client. You can, for example, use the method described in the article On the client! Get XML! Get XSL! Make XHTML! March! . But that would be too easy, because each browser adds a few nuances when working with XSLT.

Questions about how to download xsl- and xml-files and their processing in various browsers were discussed in the above article. Consider other questions:
1) inclusion;
2) caching;

All examples are published on this page ra-project.net/xsl_tests and work in browsers Opera, Chrome, IE6, Firefox, Safari.

Inclining

Simple instruction of the form
<xsl:include href="common/forms.xsl"/> ,
which works perfectly in the case of xsl-transformation on the server, when parsed in some browsers will not be processed correctly. All browsers will be able to upload an additional xsl file if the full URL is specified to it. For example:
<xsl:include href="http://site.com/xsl/common/forms.xsl"/> .
')
You can in the xsl-files that will be loaded by the browser, write the full path. But then the elegance of the solution is lost. And not always we know for sure on which domain the site will spin. Therefore, before doing the transformation on the client, it is necessary to replace relative paths with absolute paths using javascript.

In the Test Incurrent example, a single incloud is processed. Here the main xsl file 1.xsl loads the additional markup file 1_1.xsl .

In the example " Test double inludging " double incloud is processed. Here the main xsl file 2.xsl loads 2_1.xsl , which in turn refers to another xsl file 1_1.xsl .

Caching

Firefox, Chrome and Opera caches downloaded files by default, as well as regular media files. So, if you refresh the site page, the cache will lose relevance and the files will be downloaded from the network again.

IE does otherwise. It caches this data once and for all (for a long time), so even after refreshing the page, the browser will be firmly convinced that previously uploaded files have not lost their relevance. The only option to update the data is to clear the browser cache manually.

Therefore, if we need the site to display the actual data that comes to us in the form of xml, then we need to add the postfix. Like so ra-project.net/xsl_tests/res/1.xml?_1234567890666 ra-project.net/xsl_tests/res/1.xml?_1234567890666 . And the caching itself is implemented in javascript. The same applies to file transformations. For example, at the development stage, we want our browser to always operate with a “fresh” version of the xsl file, and in production you can even allow the browser to cache this xsl file.

In the example " Test Incurrent " you can "play" caching settings. The results of the settings can be observed using debugging tools: Firebug, Dragonfly, Developer Tools.

Tools used

For the client side xsl transformation, I used a plugin for the jQuery Transform , which added caching features and refined the integration mechanism. A finalized version can be taken here ra-project.net/xsl_tests/jquery.transform.js .

Not considered issues

There are still 2 unanswered questions:
1) debugging with loading and transformation errors;
2) The problem of processing the disable-output-escaping = "yes" instruction in firefox.
About them another time.

UPD. A real working example of using this technique.
juick.ra-project.net/stats#ra
This displays statistics for posts by month. When you click on a particular month, the xml data of the month and the xsl file are loaded. And the xsl-file will be loaded only once. And the xml-data is cached, so if you “walk” through the list of months, once downloaded data will not be taken from the server again, but taken from the cache.