Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >><snip/>
> >>
> >>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
> >so).
> >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 ?
>
Yupp
> 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.
>
I hope this will work out of the box. (Ok, some problems have to be solved
for this to work, but I don't expect real problems there).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
