cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: [c3] Pipeline results
Date Wed, 24 Dec 2008 14:26:04 GMT
Reinhard Pötz wrote:
> Carsten Ziegeler wrote:
>> Reinhard Pötz wrote:
>>> But still there is one limitation that has bugged me several times: The
>>> result of all pipelines is that they write something into an output stream.
>>> That's the original use case for pipelines used in servlet environments
>>> and probably true in many cases but not in all.
>>> One use case that I have is that I want to get the SAX events written
>>> into a SAX buffer or some might want to make the pipeline write into
>>> some content handler directly that they pass to it.
>>>
>>> Another use case is when you want to use pipelines to create business
>>> objects as their result. (I guess Simone can give more details here.)
>>>
>>> In all these cases you don't need an output stream.
>> Yes, I had recently the same idea when I wanted to write the output to a
>> writer instead of an output stream (now this is easy to do with a
>> wrapper but still it could be easier).
>>
>>>                                   - o -
>>>
>>>
>>> In order to make the pipeline result pluggable, I propose following
>>> changes:
>>>
>>> I would like to introduce a generic Result interface which is the
>>> transport vehicle for the actual result:
>> Ah, here we have the new interface :)
>>
>>> public interface Result<T> {
>>>
>>>     void setResultObject(T o);
>>>
>>>     T getResultObject();
>>> }
>>>
>>> And here is a possible implementation of a Result that carries
>>> an output stream:
>>>
>>> public class OutputStreamResult implements Result<OutputStream> {
>>>
>>>     private OutputStream os;
>>>
>>>     public OutputStream getResultObject() {
>>>         return os;
>>>     }
>>>
>>>     public void setResultObject(OutputStream o) {
>>>         this.os = o;
>>>     }
>>>
>>>     public String getContentType() {
>>>         ...
>>>     }
>>>
>>>     public long getLastModified() {
>>>         ...
>>>     }
>>> }
>>>
>>> The pipeline interface would have to change accordingly:
>>>
>>> public interface Pipeline<T> {
>>>
>>>     void addComponent(PipelineComponent pipelineComponent);
>>>
>>>     void addComponent(Finisher<T> finisher);
>>>
>>>     void execute() throws Exception;
>>>
>>>     void setup(Result<T> result);
>>>
>>>     void setup(Result<T> result, Map<String, Object> parameters);
>>>
>>>     void setConfiguration(Map<String, ? extends Object> parameters);
>>> }
>>>
>>> As you can see, the methods getContentType() and getLastModified() were
>>> moved to the result object where they fit much better IMO because both
>>> are specific for our output stream use case.
>>>
>>> And thanks to generics, the compiler makes sure that only a Finisher (=
>>> serializer) can be added to the pipeline if it supports a particular
>>> result type:
>>>
>>> public interface Finisher<T> extends PipelineComponent {
>>>
>>>     void setResult(Result<T> result);
>>> }
>>>
>>>
>> Hmm, not sure :) How does this it actually work - what does a serializer
>> need to do?
> 
> The serializer has to fill the result object with some content.
> 
>> 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.

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.

WDYT?

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Mime
View raw message