cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
Date Wed, 03 Apr 2002 07:53:21 GMT

Sylvain Wallez wrote:
> <snip>
> Also, Carsten, can you please explain how a SourceResolver fetched from
> a CM will handle the per-request data used to resolve sources, i.e. the
> Environment and Processor used by SitemapSource and the context prefix
> set by sitemap mounts ? Will this be based on RequestLifecycleComponent,
> or a special CM ?
It's a special CM already in Cocoon, the CocoonComponentManager. If you
lookup the source resolver you don't get the real configured source
resolver but a wrapper. This wrapper knows the current environment,
the current sitemap, context etc.
If a source should be resolved, the wrapper passes these information
to the real source resolver.

Well, that's the theory. It is already implemented, but I didn't have
time to test it.

> >>>The splitting into those two objects was done to help implementing the
> >>>cocoon: protocol. But AFAIK everywhere always those two objects are
> >>>used in combination, even in the SitemapSource class implementing the
> >>>cocoon: protocol.
> >>>
> >>Be careful : we must keep an "XML exit point" on the new
> Pipeline, since
> >>toSAX() on a SitemapSource outputs the XML just before the serializer,
> >>in order to avoid parsing of the output of the serializer. For this, we
> >>could either allow the serializer to be set more than once, or
> add a new
> >>process(environment, XMLConsumer) method.
> >>
> >
> >Yes, I know - I thought that it would be enough to call the setSerializer
> >method twice then.
> >
> I'm more in favor of process(env, consumer) since setting a new
> serializer on the pipeline in toSAX() loose the one set by the sitemap
> and thus precludes calling successively toSAX() and getInputStream() on
> a SitemapSource. I'm not sure this effectively happens, but you can be
> sure someone will do it someday ;)
> Thoughts ?
Hm, perhaps you're right. Ok, let's continue this discussion when we get
to the implementation and then we will see how the things work.


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

View raw message