cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schlichtherle" <christ...@schlichtherle.de>
Subject Discussion: Postponing XSL processing to browsers
Date Fri, 01 Jun 2007 10:39:10 GMT
Hi everyone,
 
(this is a long mail to start a discussion about postponing XSL processing
to browsers - please skip if you don't mind)
 
Recent browsers (MSIE 7, Firefox 2 and may be many more) support XSL 1.0
stylesheets or better. So it should not be a new idea to split up an XML
processing pipeline in Cocoon in two parts:

1.	Create arbitrary XML data or document.
2.	Detect browser's XSL support. If not supported, transform the XML to
(X)HTML with a stylesheet as usual. If present however, just add a
processing instruction with a reference to the same stylesheet to the XML
data or document.

The advantages of this simple architecture are obvious:

*	The (X)HTML rendering can be delegated to the client.
*	The stylesheet may be a cacheable element which is used in all
server responses, so that the browser and the server only need to transfer
XML on subsequent requests.

This should make a web application much more scalable.
 
Implementing this as a Cocoon pipeline is straightforward: First there needs
to be a conservative selector which detects the broswer's XSL support. For
the first attempts, I use something like this:
 
    <map:components>
        <map:selectors default="xslbrowser">
            <map:selector logger="sitemap.selector.xslbrowser"
name="xslbrowser" src="org.apache.cocoon.selection.BrowserSelector">
                <browser name="xsl" useragent="MSIE 7"/> <!-- Internet
Explorer 7+ (no regex support here) -->
                <browser name="xsl" useragent="MSIE 8"/>
                <browser name="xsl" useragent="MSIE 9"/>
                <browser name="xsl" useragent="Gecko"/> <!-- Firefox and co.
-->
            </map:selector>
        </map:selectors>
    </map:components>

And the processing pipeline looks similar to this:
 
    <map:pipelines>
        <map:pipeline>
            <map:match pattern="*.html">
                <map:generate src="{1}.xml"/>
                <map:select type="xslbrowser">
                    <map:when test="xsl">
                        <!-- Smart browser: Add processing instruction for
XML stylesheet. -->
                        <map:call resource="add-xml-stylesheet">
                            <map:parameter name="href"
value="{request:contextPath}/resources/xml2xhtml.xsl"/>
                            <map:parameter name="type" value="text/xsl"/>
                        </map:call>
                    </map:when>
                    <map:otherwise>
                        <!-- Dumb browser: Perform XSLT on server. -->
                        <map:transform src="/resources/xml2xhtml.xsl"/>
                    </map:otherwise>
                </map:select>
                <map:serialize type="xml"/>
            </map:match>
        </map:pipeline>
    </map:pipelines>

After some initial tests with Firefox 2 and Internet Explorer 7, my results
are very, very promising: The integration is a transparent experience for
the user and speeds up the browsing noticeably. You can only tell the
difference by looking at the document source in the browser.
 
To add some smarts to the stylesheet while reqstricting it to be XSL 1.0,
I've added some more stuff to the processing pipeline so that the XSL
stylesheet gets preprocessed by JXTemplate based upon some query parameters.
Though not processed by the browser, the query parameters had to be added to
the xml-stylesheet processing instruction so that the browser correctly
caches the stylesheet. Again, this seems to work perfectly.
 
Now I wonder if anybody else has similar experience with this obvious
approach and what they are. In particular I would be interested to learn
about other browsers which support XSL 1.0 (Opera?, Safari?).
 
I also wonder who is using such an approach in public web applications. I
have never noticed a web app which uses this technology, but due to its
transparency I just might have missed it.
 
Kind regards,
Christian Schlichtherle
-- 
Schlichtherle IT Services
Wittelsbacherstr. 10a
10707 Berlin
 
Tel: +49 (0) 30 / 34 35 29 29
Mobil: +49 (0) 173 / 27 12 470
mailto:christian@schlichtherle.de
http://www.schlichtherle.de <http://www.schlichtherle.de/> 
 

Mime
View raw message