On 28.May.2003 -- 09:25 AM, Nicola Ken Barozzi wrote:
> Marc Portier wrote, On 28/05/2003 8.38:
> >
> >Miles Elam wrote:
> ...
> >>What is the purpose of resources if this new syntax goes into effect
> >>(which I like by the way)? What can a resource do that an overloaded
> >>pipeline element cannot?
> >>
> >
> >I think as Stefano said (slightly rephrased): it would deprecate the use
> >of resources that are only fragments of pipelines.
>
> Then we are basically killing resources, as complete pipelines can
> already be used instead of resources.
>
> ...
> >Is this more then an issue of naming this concept?
>
> I mean, if we make use of resources as callable full or partial sitemap
> snippets, what would we loose that we instead get from using this new
> concept?
What I would envision here is that these pipeline fragments are on par
with ordinary sitemap components. We had this discussion before (a
long long time ago) but then it didn't gain much interest. Looks like
the time has come :-)
If we look at it, there is no reason why something that exhibits the
properties of say a transformer, that is, being a XMLConsumer and a
XMLProducer, be treated differently from a monolithic transformer.
So one would use (a subclass of) the TreeProcessor to build new Avalon
components from pipeline fragments. Condition is, the aggregate
exhibits the same interface as the other components in this group:
Generator, Transformer, Serializer, Reader.
The current Resource == Serializer (i.e. XMLConsumer + SitemapOutputComponent).
The "new" Resource == Reader (i.e. SitemapOutputComponent)
Well then, no need to keep it ;-)
If we are talking blocks, these pipelines behave like ordinary Avalon
components and we don't need to worry about how to make them available
to other blocks as this would be the same.
However, these fragments need to allow all (most of?) the sitemap
constructs IMO : e.g. chosing the right transformation step for a
client browser makes perfect sense to put into such a fragment.
What I see is for instance
<map:transformers>
<map:transformer logger="sitemap.transformer.encodeURL"
name="encodeURL"
src="org.apache.cocoon.transformation.EncodeURLTransformer"/>
<map:transformer logger="sitemap.transformer.browser"
name="renderForBrowser"
src="org.apache.cocoon.components.treeprocessor.sitemap.TransformerNodeBuilder">
<map:select type="browser">
<map:when test="netscape">
<map:transform src="stylesheets/{foo}/netscape.xsl" />
</map:when>
<map:when test="explorer">
<map:transform src="stylesheets/{foo}/ie.xsl" />
</map:when>
<map:when test="lynx">
<map:transform src="stylesheets/{foo}/text-based.xsl" />
</map:when>
<map:otherwise>
<map:transform src="stylesheets/{foo}/html.xsl" />
</map:otherwise>
</map:select>
</map:transformer>
</map:transformers>
<map:pipelines>
<map:pipeline>
<map:match pattern="*">
<map:generate type="file" src="{1}"/>
<map:transform type="browser">
<map:parameter name="foo" value="bar"/>
</map:transform>
<map:serialize/>
</map:match>
<map:pipeline>
</map:pipelines>
Even passing parameters to the transformer could be achieved easily by
adding them to the stack of sitemap variables.
There is one problem though: dependencies among such declarations
would make eager initilization difficult. Lazy initialization would
produce errors only run-time so a mixture needs to be applied.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
