jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eduardo Pelegri-Llopart <Eduardo.Pelegrillop...@eng.sun.com>
Subject Re: PROPOSAL: tag pipelining
Date Fri, 23 Feb 2001 15:35:02 GMT
I think it would be great to explore this space.  It has been in my todo
list for a while.  A variation is to explore SAX-aware or perhaps
JDOM-aware tags in a similar manner.

If enough consensus were reached, the tag interfaces could migrate into
an official standard.  The SAX/JDOM type of tags could even interact
automatically with JSP in XML syntax so XML elements are passed as
events.

	- eduard/o


James Strachan wrote:
> 
> 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: james@metastuff.com
> 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.
> __________________________________________________________________

Mime
View raw message