Exactly. That composition stage can either take place during installation of the stylesheet onto the server, or could be done by the server each time the stylesheet is requested. (In most cases, the former is the better choice.)
This gives you the benefits of modularity during development, while tolerating the broken processor on the client's end of the wire. (BTW, it would be a Good Thing for the XSLT community if you would submit a bug report to the folks maintaining those broken processors. More complaints, especially supported with real-world customer use cases, increases the odds that they'll be fixed and improve the environment for everyone.) ______________________________________ "... 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: Nathan Nadeau <n...@gleim.com> To: arnaud.diede...@erdas.com Cc: xalan-j-users@xml.apache.org Date: 08/03/2010 11:19 AM Subject: Re: Serializing a (composed) XSL 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 (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
