jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <ja...@metastuff.com>
Subject Re: PROPOSAL: tag pipelining
Date Thu, 01 Mar 2001 10:59:58 GMT
Hi Pierre

Thanks for your comments, I think I now fully understand your proposal  Just
a couple of points about properties...

From: "Pierre Delisle" <pierre.delisle@sun.com>

> Just as you bring up at the end of your email, I'd expect the
> properties in the consumer tag to have a single setter
> method (sorry if it was not clear).

Agreed, its probably simpler for users to go that route.

> This property does not
> however have to be of type 'Object', it could be of *any* type
> 'understood' by <tag:set>.

Sure. I was just thinking from a tag developer's perspective, I'd want my
tag to be as flexible as possible. So if I was building (say) the xsl:apply
tag I might want people to be able to specify an InputStream, a Reader, a
String URI or the actual text to use to for the XML.

So people could do all of these (ignoring the xsl attribute for clarity):-

<xsl:apply xml="foo.xml"/>
<xsl:apply xml="<%= request.getInputStream() %>"/>
<xsl:apply xml="<%= new FileReader( something ) %>"/>
<xsl:apply>
    <tag:set property="xml"> <root>here is some XML</root> </tag:set>
</xsl:apply>
<xsl:apply>
    <tag:set property="xml"><file:in name="foo.txt"/></tag:set>
</xsl:apply>

And with the current JavaBean spec you have 2 choices when implementing the
'consumer' tag:-

    * have 1 property of type Object and figure out what you're given and
act accordingly

    * have multiple properties of each type (Stirng, InpuitStream, Reader,
BodyContent (though BodyContent could be passed in as a Reader).

As has been discussed recently on taglibs-dev/user I think, the JavaBeans
(and hence JSP custom tags) spec doesn't allow 1 property of multiple types,
hence my comments about the property of type Object.

> It is the job of the <tag:set> tag to introspect the
> methods in the consumer tag to find the set<propertyname>
> method, figure out its argument type,
> and do the appropriate casting from the type it got from the
> producer tag. (agree, agree, lots of work... has a definite
> impact on performance)

OK. So if, say, a <file:in> tag produced an OutputStream object then the
<tag:set> would figure out that, say, the <xsl:apply> took a Reader and do
all the conversions under the covers.  i..e. put all the conversions in one
place rather than in each tag.

This is certainly possible and has a certain charm to it (putting all the
complext stuff in one place).

Though when it comes to converting between Stirng/Reader and InputStream
(say), often the tag is better aware of how to do it well than a generic
<tag:set> (e.g. when doing XML parsing using character sets). Also putting
the 'type mulitplexing' in the <tag:set> tag would make each consumer tag
less useful in its own right. For example:-

>    public ApplyTag {
>      public void setXml(Reader reader) {
>        ...
>      }
>
>      public void setXsl(Reader reader) {
>        ...
>      }
>    }

This tag could only be used as follows:-

<xsl:apply xml="<%= someReader %>"/>

or

<xsl:apply>
    <tag:set property="xml">something</tag:set>
</xsl:apply>

The common use case isn't allowed:-

<xsl:apply xml="foo.xml"/>

So IMHO it is often preferable for at least 2 types of property to be
catered for, a Stirng URI/URL and a 'Reader/InputStream'.


<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