James,
On your last email you made the following observation:
> The common use case isn't allowed:-
>
> <xsl:apply xml="foo.xml"/>
I've been struggling with this for the past couple weeks as I
was working on the 'iotransformer' taglib.
Here is how I've come to look at it:
Why should the <xsl:apply> tag have to worry about 'other' data
sources, besides the 'basic' ones (e.g. String, InputStream,
Reader)?
Why should the tag have to understand URLs as datasources?
Why accept URLs and not jdbc requests? What about jndi?...
Seems to me it would be much better to leave the task
to the specialists in the matter, namely
the jakarta 'http' taglib :-) (you wrote it, right!) for URLs,
the jakarta-taglib jdbc taglib for database access, and the jndi
taglib for jndi.
Just as you first proposed with your 'pipeline' proposal,
why not try to have taglib design principles that leverage what Unix
taught us: a good set of tools that work well together via pipes.
Through the pipe model, I believe we can have an elegant
solution that allows us to set attribute values from nested
tags. This is in fact the big thing we're after in all these
discussions, right?
Let me repeat this so it does not get lost :-)
The 'pipe model' is an elegant solution to allow
the setting of tag attribute values from nested tags.
For example, let's redesign the 'xsl' taglib with the 'pipe' approach.
Two attributes are defined for the tag:
- xml (the XML source document to be processed),
- xsl (the XSL stylesheet)
The value specified for these
attributes *must* either be a String that represents the "real" data
(i.e. the xml/xsl document itself; not a uri, a bean id, etc...)
or a runtime expression that yields a String or an object from
which the real data can be extracted (supported types (e.g. String,
InputStream, Reader) would be documented with the tag).
For example, this is the standard use case:
<xsl:apply
xml="<%= anyTypeSupportedByTheTag %>"
xsl="<%= anyTypeSupportedByTheTag %>"/>
Any other data source would also be supported *implicitely* via the 'pipe'
mechanism; i.e. both the xsl and xml attributes could have
their values set via nested tags through the use of the
'pipe' model.
And as I struggle more and more with the 'pipe' concept, it seems
that the intent of your original proposal (with slight modifications)
is what will give us the cleanest model. (10 more points for
you :-))
Within a 'pipe enabled world', this could yield the following:
Ex 1: XML from a URL - XSL inline
<xsl:apply>
<http:request ... pipeProperty="xml">
<io:inline pipeProperty="xsl">
... xsl stylesheet inline...
</io:inline>
</xsl:apply>
As you can see, I've added one attribute ('pipeProperty') that
any data-source-tag would have to implement to get direct
access to a property of the consumer side of the pipe.
(more on this on my next email).
The inline tag is a data-source tag that simply uses its
body content as the data-source.
Ex 2: XML from a database, XSL from a web-app resource
<xsl:apply>
<jdbc:... pipeProperty="xml"/>
<io:resource name="/xsl/employees.xsl" pipeProperty="xsl"/>
</xsl:apply>
This yields, imho, a pretty clean way to support setting the values
of tag attributes from nested tags (those nested tags being
what we call 'data sources', aka data-producer tags),
without adding any complexity to the tags involved,
besides support for the 'pipe' model.
One special case of this is when only one attribute of a consumer
tag can accept input from nested tags. Or maybe this is the other
way around: the normal case is when only a single attribute
can be set from nested tags, and the special case is when
more than one property can be set from nested tags.
At any rate, things would be simpler in the single attribute case
because there would be no need to specify the 'pipeProperty'
attribute in the data-source tag, and the consumer tag could
allow getting the value of that attribute directly from its
body content (removing in that case the need for an 'inline' tag as was
the case for the xsl tag above).
I think we're really getting there :-) My next email will add some
details to your amended proposal. Looking forward to hear more
comments.
-- Pierre
