Thanks for pointing it out again.
Giacomo On Wed, 3 Apr 2002, Stefano Mazzocchi wrote: > Sylvain Wallez wrote: > > > 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 ? > > When I designed the pipelines for Cocoon2, I thought about serializers > as a mix between a 'facade' and an 'adapter': pipelines are SAX based, > but the world is octet based, so we needed a way to 'adapt' between the > two. > > In this regard, the serializer is a commodity. In theory, is not even > part of the pipeline, but it's the final step to 'adapt the result to > the outside world'. Some serializers, then became more complex and > performed juicy functionalities, but only to 'adapt' to other worlds > (PDF or JPG for clients unable to handle FO or SVG directly). > > Now, if you think as serializers as 'wrappers' of SAX output, you also > understand why 'internal pipelines' don't need them and you also > understand why 'pipeline views' need serializers as well. > > But you also understand why I don't want serializers to be regular > sitemap components: because they should *not* change the result of the > pipeline, they are just adapters!!!! > > Now: if we *design* serializers *not* to mess with the content of the > stream, just to 'adapt' it to some other world, we don't need to make > the caches aware of them!!! because, from the caching perspective, > having an FO document or the translated PDF doesn't matter if the > 'serializing behavior' can be considered unchangeable. > > So, I still remain -1 on this also because it forces people to think > differenently and factor-out the logic that requires access to the rest > of the pipeline components into a transformer and place that *before* > the serializer. > > This makes it also possible to 'reuse' that refactored logic outside of > the serializer. > > So I remain -1 until one exposes me with an example that it can't be > refactored in such a way (or it is more elegant *not* to refactor it in > such a way). > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
