Solving Client Side XSLT Processing Issues

    You are already using XSLT as a template engine on the server. The turn has come 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 simple, because each browser adds several of its nuances when working with XSLT.

    Questions about the method of downloading xsl and xml files and their processing in various browsers were discussed in the above article. Consider other issues:
    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.

    Including


    Simple instruction type
    ,
    which works fine in the case of xsl-transformation on the server when parsing certain browsers will not be correctly processed. All browsers will be able to load an additional xsl file if the full URL is specified to it. For example as follows:
    .

    It is possible to specify full paths in xsl files that will be loaded by the browser. But then the elegance of the solution is lost. And we don’t always know for sure which domain the site will be spinning on. Therefore, before doing the transformation on the client, you must use javascript to replace the relative paths with absolute ones.

    In the Test Inclusion example, single inclusion is processed. Here the main xsl file 1.xsl loads the additional markup file1_1.xsl .

    In the Double Inclusion Test example, double inclusion 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 default to cache downloaded files, just like regular media files. So, if you refresh the site page, the cache will lose its relevance and the files will be downloaded from the network again.

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

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

    In the “ Test Inclusionexample , you can “play around ” with the cache settings. The results of the settings can be observed using the debugging tools: Firebug, Dragonfly, Developer Tools.

    Used tools


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

    Pending Issues


    There were 2 more issues that were not considered:
    1) debugging during loading and transformation errors;
    2) the problem of processing the disable-output-escaping = "yes" statement in firefox.
    About them another time.

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

    Also popular now: