cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi" <simone.trip...@gmail.com>
Subject Re: [c3] Pipeline results
Date Tue, 23 Dec 2008 10:43:34 GMT
Hi Reinhard,
thanks to mentioned me :P I like your proposal and, indeed, is what we
start thinking when I submitted the Digester Finisher[1] patch; in the
testcase, there's the demonstration that the Finisher had to be
"forced" using a null OutputStream - otherwise the Pipeline couldn't
start - then parsing the XML events throught the Digester and after
all getting the result object using the specific Digester methods. Of
course, it works, but IMHO it's a little tricky.

The main point - that I suppose induced Reinhard thinking about the
interfaces introduction - is that the Pipeline module should be useful
not only to serialize XML events, but also to process them in
different ways, like mapping and XML document to Java objects, not
necessarily with Apache Digester.

Introducing the new interface, users can avoid to "hack" the finisher,
but rather using the Pipeline in a clear and documented way.
I like Reinhard's ideas, they make the Pipeline module multi-purpose
just introducing new small concepts.

Best regards,
Simone

[1] https://issues.apache.org/jira/browse/COCOON3-8

2008/12/23 Reinhard Pötz <reinhard@apache.org>:
>
> Triggered by some discussions that Steven and I had with our students we
> were thinking again about the pipeline API. Compared to previous
> pipeline implementations we already made one improvement by making the
> pipeline unaware of the data that flows between its components. This
> means that the Cocoon 3 pipeline implementation doesn't impose any
> limitations if it is SAX or StAX or whatever that is passed
> from one component to another.
>
> 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.
>
>
>                                  - 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:
>
> 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);
> }
>
>
> 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
> ________________________________________________________________________
>
>



-- 
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Mime
View raw message