Tags can be nested with others, so that, for example, the result of a SOAP
request can be styled using the xsl tag library (which is kinda cool)...
<xsl:apply xsl="format_babelfish.xsl">
<http:soap
url="http://services.xmethods.net:80/perl/soaplite.cgi"
SOAPAction="urn:xmethodsBabelFish#BabelFish">
<http:body>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:BabelFish xmlns:m="urn:xmethodsBabelFish">
<translationmode>en_fr</translationmode>
<sourcedata>SOAP is quite easy with JSP.</sourcedata>
</m:BabelFish>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
</http:body>
</http:soap>
</xsl:apply>.
Though there is a small inefficency due to double buffering. The output of
the <http:soap> request is sent to the pageContext's JspWriter. The
<xsl:apply> creates its own BodyContent which gets filled by the output of
the <http:soap> request. It would be nice if we had some standard mechanism
for us to avoid the unnecessary buffer and "pipe" the input and output tags
together.
This is a similar idea to Pierre's iotransformer tag library though its done
at the inter-tag level rather than via a new tag and an explicit transformer
bean. For example if we had a standard interface...
public interface InputCapableTag {
public void input( Reader reader );
public void input( InputStream in );
}
Then the <http:soap> tag could look up the tag hierarchy for a tag which
implements InputCapableTag. Then if the <xsl:apply> tag implemented
InputCapableTag, the <http:soap> tag could pass the InputStream or Reader of
the result of the soap request directly to the <xsl:apply> tag without the
need for the output to be written to the BodyContent first.
A similar pattern in reverse could be done to supply the body of a
<http:request action="POST">. For example...
<http:soap
url="http://services.xmethods.net:80/perl/soaplite.cgi"
SOAPAction="urn:xmethodsBabelFish#BabelFish">
<http:body>
<xsl:apply xsl="make_soap_request.xsl">
<m:BabelFish xmlns:m="urn:xmethodsBabelFish">
<translationmode>en_fr</translationmode>
<sourcedata>SOAP is quite easy with JSP.</sourcedata>
</m:BabelFish>
</xsl:apply>
</http:body>
</http:soap>
In the above example, we're using the <xsl:apply> tag to create the body of
the SOAP request. So here the <xsl:apply> tag creates the input and the
<http:soap> uses it for the body fo the HTTP POST. Again double buffering is
done - the output of the <xsl:apply> tag is written to the BodyContent of
the <http:body> tag first before being read and output to the
HttpURLConnection inside the <http:soap> tag.
It would be nice if we could avoid using the <http:body> tag completely and
instead use inter-tag communication (or "tag pipelining") as follows:-
<http:soap
url="http://services.xmethods.net:80/perl/soaplite.cgi"
SOAPAction="urn:xmethodsBabelFish#BabelFish">
<xsl:apply xsl="make_soap_request.xsl">
<m:BabelFish xmlns:m="urn:xmethodsBabelFish">
<translationmode>en_fr</translationmode>
<sourcedata>SOAP is quite easy with JSP.</sourcedata>
</m:BabelFish>
</xsl:apply>
</http:soap>
In this case the <xsl:apply> tag searches the tag hierarchy for an instance
of OutputCapableTag
public interface OutputCapableTag {
public void output( Writer writer );
public void output( OutputStream out );
}
and so rather than the <xsl:apply> tag outputting its results directly to
the BodyContent it pipelines it straight into the <http:soap> tag which
results in the output being written straight through to the
HttpURLConnection.
It would be nice of some mechanism like the above could be adopted
throughout the jakarta-taglibs project as a standard way of pipelining tags
using nesting. So multiple 'pipelines' can be achieved as follows...
<file:write file="foo.txt">
<regexp:subsitiute from="foo" to="bar">
<xsl:apply xsl="something.xsl">
<http:request url="foo" action="POST">
<xsl:apply xsl="a.xsl" xml="bar.xml"/>
</http:request>
<xsl:apply>
</file:write>
This turns out to be quite similar to Pierre's proposal but done implicitly,
where each JSP custom tag becomes a a kind of 'transformer bean' and they
can connect their input/output together via tag interfaces (InputCapableTag
and OutputCapableTag).
If something like this gets accepted then it would be nice to have some
small core library "jakarta-core.jar" that contained the above interfaces
(and maybe some other helper / utility classes) that could be shared across
all of the tag libraries so that all jakarta-taglibs could efficiently
pipeline together.
Does this seem a reasonable idea?
<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.
__________________________________________________________________
