James,
My comments at the end.
James Strachan wrote:
>
> 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'.
I see your point. By having all conversions done in <tag:set>, this
prevents runtime expressions from returning any type other
than the single one supported for the attribute.
Your initial assumption about a single 'Object' type therefore makes
more sense. Two points for you :-).
With respect to
> The common use case isn't allowed:-
>
> <xsl:apply xml="foo.xml"/>
my next email will try to address that.
-- Pierre
