You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Arnaud Diederen <ar...@erdas.com> on 2010/08/03 14:41:23 UTC
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.
Re: Serializing a (composed) XSL
Posted by ke...@us.ibm.com.
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 <nd...@gleim.com>
To:
arnaud.diederen@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, keshlam@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 <ar...@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
ndn@gleim.com
Software Development
Gleim Publications, Inc.
http://www.gleim.com
Re: Serializing a (composed) XSL
Posted by Nathan Nadeau <nd...@gleim.com>.
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, keshlam@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 <ar...@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
ndn@gleim.com
Software Development
Gleim Publications, Inc.
http://www.gleim.com
Re: Serializing a (composed) XSL
Posted by ke...@us.ibm.com.
I think I've already posted my thoughts to the list. At some time before
shipping the stylesheet to the client, run it through another stylesheet
which finds the xsl:include directives, extracts their specified URIs, and
uses xsl's document() function to replace the includes with the contents
of the included file. Should be easy to write.
I don't think you "lose" anything by doing so. xsl:include is pretty
straightforward. xsl:import, on the other hand, would require more logic.
______________________________________
"... 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 <ar...@erdas.com>
To:
keshlam@us.ibm.com
Cc:
xalan-j-users@xml.apache.org
Date:
08/04/2010 10:11 AM
Subject:
Re: Serializing a (composed) XSL
Joseph,
would you have any further thought on this?
Thanks,
A.
On Tue, 2010-08-03 at 16:35 +0200, Arnaud Diederen wrote:
Joseph,
On Tue, 2010-08-03 at 08:59 -0400, keshlam@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 <ar...@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.
Re: Serializing a (composed) XSL
Posted by Arnaud Diederen <ar...@erdas.com>.
Joseph,
would you have any further thought on this?
Thanks,
A.
On Tue, 2010-08-03 at 16:35 +0200, Arnaud Diederen wrote:
>
> Joseph,
>
>
> On Tue, 2010-08-03 at 08:59 -0400, keshlam@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
> > <ar...@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.
> >
> >
> >
> >
Re: Serializing a (composed) XSL
Posted by Arnaud Diederen <ar...@erdas.com>.
Joseph,
On Tue, 2010-08-03 at 08:59 -0400, keshlam@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
> <ar...@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.
>
>
>
>
Re: Serializing a (composed) XSL
Posted by ke...@us.ibm.com.
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)?
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 <ar...@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.