Hi Pierre
How about we combine both of our proposals and say that:-
* <tag:set> is developed and used throughout all jakarta-taglibs to allow
attributes of any type to be specified in a very flexible way. (I'd like it
to be included as a standard part of JSP too!). It should just use regular
introspection and not do too much complex type mangling to pass objects
between tags.
* a producer tag can produce any type it wishes
* a consumer tag can consume any type it wishes
When using <tag:set> for pipelining of tag input/output to avoid double
buffering...
* a consumer tag could be written to accept various different types,
especially InputStream, Reader and a String URI/URL (e.g. like <xsl:apply>)
and its recommended that the same property name is used (e.g. "xml") and the
type be Object. This makes it easier from the JSP users and makes life for
<tag:set> easier.
* producer tags could produce Reader if possible or InputStream if not.
Worst case they can write to their own JspWriter and <tag:set> will pass its
BodyContent through to the consumer tag as a Reader instance (double
buffering would then occur).
* for simple pipelining, where there is an obvious well defined input ->
transformer -> output style pipelining via tag nesting, then one or two
simple interfaces (TBD) may be used to avoid the need for the <tag:set> tag.
This would be slightly more efficient as the producer and consumer tags
would communicate directly using typesafe methods without the need for
introspection or the middle-tag. This does pose an extra burden on the tag
developer. If a tag developer didn't implement these interfaces, then
<tag:set> tag can always be used to still avoid double buffering in
pipelining.
<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.
__________________________________________________________________
