cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [c3] Pipeline results
Date Sun, 04 Jan 2009 13:12:03 GMT
Carsten Ziegeler wrote:
> 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).

yes, I meant it that way.

> 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)

They can still produce an OutputStream. I have no problem with that.

> 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
> whatever).
> So in the end your result object type depends heavily on the used finisher.

Yes and I don't think that there speaks anything against it: One
serializer can produce one particular result type.

The problem that I want to solve is that a pipeline can produce other
results than OutputStreams which imposes an unnecessary limit or makes
things ugly because you have to produce something that you don't need
and use a hack to get out what you really want.

I think we all agree on this.

The question we have to answer now is, how to we want to get access to
the produced result. As pointed out before, I don't think that it is a
good idea if you have to ask the finisher to get the result. If we do it
this way, we would probably have to expose the finisher via the pipeline
API. I'm not sure if that's the way to go.

> 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.).

yes, the situation is similar but since we already have input parameters
that can be passed in the setup method of a pipeline, it isn't as
limiting as in the output case.

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message