jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <ja...@metastuff.com>
Subject Re: PROPOSAL: tag pipelining
Date Wed, 28 Feb 2001 11:31:32 GMT
> I've had more time to look at James "pipeline" proposal.
> Definitely looks reasonable.

As does yours ;-)

> However, I'd like to throw another idea.


> I however had some concerns regarding its usage:
> 1. algorithm to link the producer to the consumer is 'tricky'

Agreed. Though a helper class could wrap up most of this code to make it
easier for tag developers. I'll experiment and report back to the list.

> 2. Requirement on the consumer tag to implement interface InputCapableTag
>    OutputCapableTag.
>    Would be great if the producer data could be linked to
>    a consumer tag's attribute directly instead...

Agreed. If I understand your proposal, you would need to expose 'streams' or
'text' as properties so that the introspection would work. For example in
the xsl tag:-

public ApplyTag {

    // set the input to use via string uris
    public void setXml(String xmlURI);
    public void setXsl(String xmlURI);

    // set the text (from a BodyContent) to use as input
    public void setXmlBody(String xmBody);
    public void setXslBody(String xmlBody);

    // set the input to use via InputStreams
    public void setXmlInput(InputStream xmlInput);
    public void setXslInput(InputStream xslInput);

    // set the input to use via Readers
    public void setXmlReader(Reader xmlReader);
    public void setXslReader(Reader xslReader);

such that your <tagio:set> tag could pass in either a URI (setXml), its body
content (setXmlBody), an InputStream  (setXmlInput) or a Reader

The advantage here is that introspection could be used or regular JSP
attribute passing expressions or even direct tag interaction between tags
that know about each other.

Though there would still be some 'negotiation' in the tag to figure out how
to read its XML.
    if ( xmlURI != null ) {
    else if ( xmlBody != null ) {
    else if ( xmlInput != null ) {
    else if ( xmlReader != null ) {

and there would be an increase in the number of properties in the tag.
Though neither of these is a big deal really.

> 3. Restricted to a single 'pipeline' attribute

Agreed. I hadn't really got that far considering tags that take multiple
inputs. Apart from the <xsl:apply> tag I haven't seen or built many tags
that take multiple inputs or generate multiple outputs. Maybe thats a case
for breaking the tag into 2?

<xsl:stylesheet uri="somestyle.xsl">
    <xsl:apply uri="foo.xml">
    <xsl:apply uri="bar.xml">

Such that 1 tag loads the stylesheet and another tag loads or provides the
XML to be styled?

> 4. Tag attributes as tags

Yes! This is definitely an area I'd like to see a nice solution, to avoid
writing superfluous 'attribute' tags that just allow an attribute value to
be specified by evaluating one or more other tags.

I think your <tag:set property="foo"/> is really useful proposal to avoid
writing attribute tags. It should be a 'standard proposal' in its own right!

    <scrape:page url="...">

    or an inner tag sets the url property

        <tagio:set property="url">... some text which can other

Great idea! IMHO this should be part of a standard 'core' tag library that
can be reused across all tag libs. Makes all tag libs more flexible!

> Advantages would be as follows:
> - generic mechanism for efficiently setting 'complex' tag attributes
> - no need to implement 'attribute' tags just to support complex
>   attribute values


> - no need to implement interfaces InputCapableTag or OutputCapableTag
>   in a consumer tag

Though the output tags would need to be changed to pass their 'InputStream',
'Reader' or 'String' objects to the <tag:set> tag and the input tags would
need to have setter methods to handle these properties being set. Though
neither of these approaches are alot of work.

> - data types supported by the consumer tag for this direct transfer
>   of data does not have to be restricted to just a few types, since
>   the <tagio:set> tag can handle all casting appropriately

Sometimes typesafety can be a good thing and sometimes not :-)

> - algorithm of the producer tag becomes very simple:
>   if parent tag is instanceof <tagio:set>
>      parent.setData(Object object)
>   else
>      simply write to the previous out

Though it does mean that the negotiation between tags isn't automatic.
Input/OutputCapableTags just click together automatically by containment -
which I like. Whereas the <tag:set> approach has to be "manually programmed"
in the coding of the <tag:set> tag. For example, using my sample of how
<xsl:apply> could be implemented above:-

<xsl:apply xsl="foo.xsl">
    <tag:set property="xmlReader"><file:in file="something.xml"/></tag:set>

Here I could have used the wrong property name for <xsl:apply> as the
<file:in> passes an InputStream rather than a Reader into the xmlReader
property which wouldn't work in introspection.

If in doubt I'd rather have the tag implementor have a bit more work to do
to have a more 'bullet proof' tag than hope that JSP editors understand what
Java types are passing around under the covers and use the right property

A work around could be that instead of having different properties for each
type of input (String/InputStream/Reader), all tags which take input should
have a single typeless property for each 'input':

public ApplyTag {
    public void setXml( Object object ) {
        if ( object instanceof Reader ) {
        else if ( object instanceof InputStream ) {
        else if ( object instanceof String ) {
            // are we the URI or the body content -
            // probably need another property for body

> Comments???

I think the <tag:set> tag rocks for the "attribute" as a tag problem. Its
also a possible solution for pipelining. Maybe combining the both approaches
together could lead to the best of both worlds. Both have their strengths
and weaknesses I think.


James Strachan
email: james@metastuff.com
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.

View raw message