cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [c3] Pipeline results
Date Mon, 29 Dec 2008 09:46:09 GMT
Reinhard Pötz wrote:
> Reinhard Pötz wrote:
>> Carsten Ziegeler wrote:
>>> There is a slight overlap between the serializer and the result - for
>>> example if you want to get java objects out of the pipeline, you might
>>> want to use a special serializer. So maybe we can merge the two?
>> I was thinking about this too but I preferred the symmetry of defining
>> the input and output objects at pipeline level and not at component
>> level. OTOH it's only the serializer which needs access to the output
>> object, hmmm ...
> The more I think about it the less I like the idea of merging the result
> and the finisher (serializer) interfaces. The reason is that you would
> have to pass the result object to the finisher which means that you have
> to do this when you create the finisher instead of doing it when you
> setup the pipeline.
Hmm, if you merge result and finisher, you don't have to pass the result
object to the finisher - it is the finisher :) But I guess you mean
something like the output stream, right? (which is currently passed to
the finisher by the pipeline object).
But I see your point - however I fear this flexibility - I guess it is
unlikely that each finisher will cope with each possible result - text
based finisher (like html or xml serializers) will be able to write to a
stream or writer, finishers creating binary content (like the pdf
serializer) will be able to write to a stream but not to a writer. Atm,
I see no other possible result format for these kind of finishers (maybe
getting the fop object model? hmm)
Now, if you want a tree of objects as a result of your pipeline, you
will have a special finisher for that (maybe a castor finisher or
So in the end your result object type depends heavily on the used finisher.

We already have a similar case with the producer/starter - we don't have
a source interface abstracting where the input for a starter is comming
from (like from a stream, reader, http request etc.).


> It would also mean that you have to keep a reference to the finisher (or
> even worse, expose the finisher via the pipeline API) in order to get
> access to the result.

Carsten Ziegeler

View raw message