Hi Pierre
Thanks for your comments, I think I now fully understand your proposal Just
a couple of points about properties...
From: "Pierre Delisle" <[EMAIL PROTECTED]>
> 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: [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.
__________________________________________________________________
