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 22:19:12 GMT
On 24.11.2003 23:04, Sebastian Klamar wrote:

> * Joerg Heinicke [2003-11-24 20:33 +0100] wrote:
>>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. 
> I've done the changes locally.  I could post a bugzilla request to make
> the change go into CVS.

Yes, this would be cool.

>>And you must let the caching be based on the two parameters.
> Yes, that needs more investigation.  But my current experience for
> the old (current) version is that caching doesn't work right!  If I
> change the configuration inside <map:components/> no new document gets
> processed.  Cocoon is delivering an old, cached version :-/

That's correct from the implementation, but wrong from the expectation I 
guess :-)

>>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 
> Nothing to do... Hmm, to my knowledge the couple of
> FragmentExtractor{Transformer,Generator} was created due to needs of
> creating SVG images that are described inside the page.  So it's a
> little bit historical.  But I agree with you, the extractor function is
> not limited to svg processing -- I use it to store a fragment or the
> whole document for later processing.

Ah, inline SVG. Hmm, I would like to remove it to the core then. Any 


> -- 
> Die letzten Worte...
>       des Formel-1 Piloten: "Ob der Mechaniker weiƟ, dass ich mit seiner
>                                                       Freundin schlafe?"

ROTFL. After reading this I had problems to write the mail :-)

View raw message