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 :) )
> >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. +1 for merging +1 for configurable pipelines Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
