Re: Serializing a (composed) XSL

Tue, 03 Aug 2010 08:15:19 -0700

I think the suggestion is to write another stylesheet that takes your existing stylesheet as the input (it is XML after all), and copies it out unchanged, except it has a template that matches <xsl:include> elements and grabs the referenced stylesheet (via document()) and then applies templates on the fetched document, thereby copying the included stylesheet and recursively processing any <xsl:include>s in the included stylesheet. Run this new "composer" stylesheet via xalan-java before sending out the resulting fully-composed single stylesheet to the browser. 

Arnaud Diederen wrote:


Joseph,


On Tue, 2010-08-03 at 08:59 -0400, kesh...@us.ibm.com wrote:

Why not use a stylesheet to style your stylesheet and bring the 
includes into a single document, rather than trying to work with 
Xalan's low-level data structures (which weren't really designed to 
be written back out as XSL)?



If I understand your suggestion correctly, what I should implement is 
some sort of mechanism that will "replace" xsl:include directives with 
the contents of the document they reference. Is that correct?



If that's the case then it's just some sort of query-replace, and I 
lose the benefits of using an XSL processor, such as: namespace/prefix 
resolution, etc...


Am I missing something?

     A.






I admit I may be biased -- I wrote the "styling stylesheets" article 
on IBM's XML Developerworks page (http://www.ibm.com/xml) -- but this 
really does strike me as being both much easier and more portable.


______________________________________
"... Three things see no end: A loop with exit code done wrong,
A semaphore untested, And the change that comes along. ..."

 -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish 
(http://www.ovff.org/pegasus/songs/threes-rev-11.html)



From:   Arnaud Diederen <arnaud.diede...@erdas.com>
To:     xalan-j-users@xml.apache.org
Date:   08/03/2010 08:47 AM
Subject:        Serializing a (composed) XSL


------------------------------------------------------------------------





Gentlemen,

I have a web application that uses, on the browser-side, XSL transforms.

Alas, because of _a little issue in WebKit 
<https://bugs.webkit.org/show_bug.cgi?id=10313>_ (affecting Google 
Chrome, Safari, ...), I cannot use /composed/ XSLTs (i.e., XSLs that 
<xsl:include>s other bits of XSL) in Chrome.



I thought I'd give xalan-java a try at solving my problem, by 
"composing" the XSLT bits into one big XSL, on the server-side.

That composed XSL could then be used by all browsers.

Here's what I had in mind:
* get xalan-java to load the XSL.
* get xalan-java to load its children.
* dump the composed XSL as String, or byte [].

And here's my first attempt at this task:



           TransformerFactory tFactory = 
TransformerFactory.newInstance();

           Transformer transformer = tFactory.newTransformer
               (new StreamSource("/path/to/xslt/common.xslt"));


           TransformerImpl transformerImpl = (TransformerImpl) 
transformer;
           StylesheetRoot stylesheetRoot = 
transformerImpl.getStylesheet();

           stylesheetRoot.recompose();
           Document stylesheetDoc = stylesheetRoot.getOwnerDocument();
           W3CNodeHelper nodeHelper = new W3CNodeHelper();

           String out = 
nodeHelper.dumpAsString(stylesheetDoc.getChildNodes().item(0));





(Where the "W3CNodeHelper" thingy is just one of our tools I use to 
dump the document.)


Unfortunately this fails, as:

java.lang.RuntimeException: ElemTemplateElement error: Function not 
supported!
at 
org.apache.xalan.templates.ElemTemplateElement.error(ElemTemplateElement.java:223)
at 
org.apache.xalan.templates.ElemTemplateElement.error(ElemTemplateElement.java:236)

at org.apache.xml.utils.UnImplNode.getAttributes(UnImplNode.java:641)

at 
com.ionicsoft.xml.dom.W3CNodeHelper.dumpElement(W3CNodeHelper.java:992)

at com.ionicsoft.xml.dom.W3CNodeHelper.dump(W3CNodeHelper.java:851)
at com.ionicsoft.xml.dom.W3CNodeHelper.dump(W3CNodeHelper.java:825)

at 
com.ionicsoft.xml.dom.W3CNodeHelper.dumpAsString(W3CNodeHelper.java:802)

at com.Test.main(Test.java:43)



I guess this method is far from ideal. Would anyone have any 
information on how I could achieve what I'm trying to?


Thanks a bunch for any info/pointer!

Regards,
       A.






--
Nathan Nadeau
n...@gleim.com
Software Development
Gleim Publications, Inc.
http://www.gleim.com























					Reply via email to