Bernhard Huber wrote: > > Hi > > I still believe that serializers are somewhat special components and > > should not have a side entry for data.... also because I believe that > > serializers should be removed from pipeline definitions... but this is > > another story. > > > That would be great, as the request contains user-agent, and > the accepts http-header it should be possible to select > the correct serializer. > That way the serializer could be removed from the pipline defintion > completly. > Did I get it right?
Well, I was thinking about internal content aggregation: since aggregation is going to be a major feature of Cocoon, I think that serializers should be added to adapt a pipeline to the external world, thus have a different semantic than today. So that doing something like this [g -> t -> t] -> S where [...] is the pipeline allows you to do aggregation without the double serialization/deserialization (parsing) stages as we do today. Moreoever, it eases the concept of views since you can do [g -(a)-> t1 -(b)-> t2 -(c)-> t3] -> S then the 'c' view of that URI [c] -> [t -> S] is translated into [g -> t1 -> t2 -> t] -> S and one could even aggregate different views without worring about serialization getting into its way. But this will requires some changes into the internal API since the cocoon:// protocol returns a byte stream not a SAX stream. So, lots of things to consider. Stefano. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
