jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Delisle <pierre.deli...@sun.com>
Subject Re: PROPOSAL: tag pipelining
Date Fri, 02 Mar 2001 02:02:41 GMT
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" <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'.

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

Mime
View raw message