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:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
