cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: [VOTE] (was: [RT]: Merging Stream And Event Pipeline)
Date Wed, 03 Apr 2002 07:37:38 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>
>>I'd like also we take a formal decision about allowing a Serializer to 
>>be a SitemapModelComponent. This comes regularly on the table, and there 
>>have been several uses cases showing the need for it, mainly to access 
>>the SourceResolver. And I've got a new use case : I'm currently adding 
>>source resolving capabilities to SVGSerializer to allow bitmaps to be 
>>read using the "blob" SourceFactory. For this, the serializer *needs* 
>>the SourceResolver and thus I have a patched version of StreamPipeline 
>>that handles this. I also know that other people are using similar hacks 
>>(Dims once sent this hack as an aswer to one of your questions).
>>
>>So : do we allow a Serializer to be a SitemapModelComponent ?
>>+1 from me !
>>
>I'm +0 on this. The new source resolver from Avalon I started to integrate
>is available via the ComponentManager, so if a serializer is Composable
>it can use the source resolver then.
>(And I'm waiting for Stefano and Giacomo to come up and give us their -1
>on this :) )
>

Yeah, I know Stefano doesn't like that, but so many people feel the need 
for it... So Stefano, if you don't like that, please give us a cool 
explanation like the one you gave for "views from last label". IIRC this 
has to do with cacheability, but CachingStreamPipeline has some 
provision for cacheable serializers. So ?

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 ?

>>>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 ?

>+1 for merging
>+1 for configurable pipelines
>
>Carsten
>

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message