cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: FragmentExtractor: component parameter vs. map:parameter for extract-{uri,element}
Date Mon, 24 Nov 2003 19:33:37 GMT
On 24.11.2003 16:45, Sebastian Klamar wrote:

> Hi,
> is there any special intension (configure component once, run many times
> with less if's for performance issues?) to configure the extract-uri
> and extract-element for the FragmentExtractorTransformer (batik
> block) inside <map:components> instead of to to make them known via
> <map:parameter>s?

I don't know what was the basis for the decision-making for the 
FragmentExtractor, but in general in <map:components/> a default 
generation is provided while it can be overridden using <map:parameter/>.

> I have a sitemap where I need the extractor with three different
> extract-{uri,element} constellations.  With the current situation I'm
> obliged to configure three different transformers (with same logger and
> src, but different extract-{uri,element}) inside <map:components>.
> That's very redundant and space wasting :-(  I'd like to configure both
> parameters every time the transformer gets called inside a pipeline with
> the help of nesting <map:parameter> elements.

The change would be really easy as you can see if you have a look at 
other transformers that are <map:parameter>izable - something I could 
even do ;-) But I don't have that much time at the moment. And you must 
let the caching be based on the two parameters.

To the others: Is there any reason this transformer is in the batik 
block? AFAICS it has nothing to do with batik and is a really simple 


View raw message