jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignacio J. Ortega" <na...@siapi.es>
Subject RE: PROPOSAL: tag pipelining
Date Fri, 23 Feb 2001 16:07:54 GMT
Great idea, James.

It seems that you proposal extendns spec .... please Shake the jsr-XX
people with the idea , perhaps could be added to 2.3 spec ..

Saludos ,
Ignacio J. Ortega


> -----Mensaje original-----
> De: James Strachan [mailto:james@metastuff.com]
> Enviado el: viernes 23 de febrero de 2001 12:26
> Para: taglibs-dev@jakarta.apache.org
> Asunto: PROPOSAL: tag pipelining
> 
> 
> 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