Attached to this email is a new port of the xsl tag library. I've had to
remove the sax2.jar and jaxp.jar from it to fit it through the lists email
size limit.
The jar includes source, sample web apps, docs etc.
I've ported the xsl tag library over to JAXP, though I've disabled by
default as I had a few problems getting JAXP1.1, Xalan and Tomcat all to
work nicely together. (In ApplyTag.java see the USE_JAXP final boolean
variable - Java's way of doing a #if directive like in C/C++).
The xsl library can now make use of the new tag pipelining mechanism so that
(say) file / ftp / http / https / xmlrpc / soap requests can all be piped
directly into the <xsl:apply> tag (for either the xml or xsl or both)
without the need for double buffering. Here's a simple use case:-
<xsl:apply xsl="foo.xsl">
<io:request url="someUrl"/>
</xsl:apply>
or both could be specified independently using any pipeline aware tags...
<xsl:apply>
<io:set property="xmlInput">
<io:request url="someXmlUrl"/>
</io:set>
<io:set property="xslInput">
<io:request url="someXslUrl"/>
</io:set>
</xsl:apply>
Also the output of the <xsl:apply> can be pipelined too so one could imagine
the following:-
<io:soap url="foo" action="bar">
<xsl:apply xsl="something.xsl">
<io:request url="bodyURL"/>
</xsl:apply>
</io:soap>
So in the above a URL request is used as input to an XSLT operation, the
output of the transform is piped into the SOAP request as the body, i.e.
HTTP POSTed into the "foo" soap request. In the above example, no double
buffering would occur - the <io:request> URL connection's stream would be
read directly by the XSLT engine in the <xsl:apply> tag and written directly
to the <io:soap> requests URL connection. No intermediate BodyContent
objects would be used.
Build process changes:
===============
The xsl library attached is now dependent on the io tag library (which has
the core pipeline code in it) and some of the xsl examples now use the io
tag library.
So the io tag library needs to be built first before the xsl tag library.
Tested on...
========
Tomcat 3.1 and WebLogic 5.1 SP6
Pierre:
====
the main problem I noticed when patching the <xsl:apply> tag to be
pipeline-aware is that having a single property of type Object lead to
problems. For example the <xsl:apply> tag started life having a property
public void setXml(Object object);
But I then got JSP compile errors when I tried to use it as:-
<xsl:apply xml="foo.xml"/>
I kept getting compile errors saying "couldn't convert from compile time
type to Object" which I thought was strange. The workaround was to use the
ugly scriplet expression form instead:-
<xsl:apply xml='<%= "foo.xml" %>'/>
Maybe thats another limitation of the current JSP spec? Or maybe a Tomcat
bug.
So for now I've implemented the tag having 2 properties, one String and one
Object:-
public void setXml(String url);
public void setXmlInput(Object object);
Such that the common String use case works fine, or when piping the
information in, the "xmlInput" property can be used instead. Ditto for the
XSL input which has properties "xsl" and "xslInput".
This issue should probably be investigated more before making the final
pipelining proposal.
Any comments?
<James/>
James Strachan
=============
email: [EMAIL PROTECTED]
web: http://www.metastuff.com
__________________________________________________________________
If you are not the addressee of this confidential e-mail and any
attachments, please delete it and inform the sender; unauthorised
redistribution or publication is prohibited.
Views expressed are those of the author and do not necessarily
represent those of Citria Limited.
__________________________________________________________________
xsl.jar
