cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [status & RT] design challenges
Date Mon, 08 Apr 2002 11:44:06 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>The major need is to be able to access the SourceResolver. I haven't
>>seen any good use case where a Serializer needs to access something else
>>in the environment. So what about a "SourceResolvable" interface handled
>>by CocoonComponentManager ?
>>public interface SourceResolvable {
>>  void setSourceResolver(SourceResolver resolver),
>>One more use case for this need : I have pending on my HD a Batik
>>ProtocolHandler that allows any Cocoon source to be used in Batik's URL
>>handling system. This allows to insert bitmaps stored in Blobs (using
>>the BlobSource in scratchpad) in SVG drawings. The only thing that's
>>needed is the SourceResolver. Nothing else.
>We don't need such interfaces in the next version anymore (at least I hope
>If a component is Composable (and Serializers can be composable), they
>can lookup the Avalon Excalibur SourceResovler.
>And this SourceResolver can then be used to resolve any URI (including all
>our nice protocols like cocoon: and of course relative URIs).
>The Avalon Excalibur SourceResolver will replace all of our uri handler,
>source handler, source resolver stuff and clean up this area. There will
>only be one! The Avalon Excalibur SourceResolver.

That's *really* great news ! So this means the SourceResolver will be 
available for every Composable component ?

The last thing we need now is a CocoonSource that can be used without an 
Environment, to be able to call "cocoon://" from components declared in 
the root CM.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message