cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Homeijer <>
Subject RE: [RT] Input Pipelines (long)
Date Tue, 07 Jan 2003 13:33:12 GMT

> Stefano Mazzocchi wrote:
>> Michael Homeijer wrote:
>> Hi,
>> I think your comment is right. It's not the (a)symmetry that's the
>> it's the "glue" that connects the input to the output thats missing or
>> implicitly available.
>Good, I'm glad we reached an agreement here.
>> Most of the time when using cocoon I use a solution/workaround of
having an
>> aggregation of an "input" pipeline (for instance writing a resource in
>> xml database) and the "output" pipeline (showing the new list of
>> in the xml database). Most of the time the "logic" of the pipeline,
>> deciding if anything went wrong, ends up in xsl.
>> Because of the way map:handle-errors works (ie. you loose context
>> information etc.) I don't think it should be used to check application
>> logic/exceptions (for instance when a resource allready exists), but
>> system execeptions. 
>I agree.
>It comes to mind that it should be the flowscript layer to handle those 
>application-level exception out of an executed pipeline... or maybe 
>not... hmmm, what do you think about this?

Until this thread started I thought about the flowscript layer to be usefull
for "inter-request" flow (mainly continuations). Not for composing the logic
that handles a request. I'm still not sure... just a gut feeling. 
The application logic and exceptions I mentioned should be able to influence
the flow through the pipelines, not be mixed with the content of the
pipelines, and IMHO certainly not break it in the case of an application

>> Another way of implementing the input part (and mixing the flow part
in it)
>> is bij coding actions. This doesn't allways work out right as well.
>> applications I build with cocoon contain far to many specific actions
>> handling input and flow, and actions are not very good at handling xml
/ sax
>> input.
>> A construction of "pipeline input - flow - pipeline output" should
>> most of these cases, but I think the real "puzzle" will be how to fit
>> in with the allready existing "pipeline setup"/"pipeline execution
>Since you agreed that pipelines aren't necessarely asymmetric, why do 
>you need to specify 'input pipelines' above?

I only meant as a sample that the two pipelines should be logically
disconnected. Some examples I have seen transform and process input and in
the process mix output and generate the output html.
For instance 
"request generator" - "transform" - "write source" - "transform into output
(maybe by aggregation)" - "serialize".
This can be done, but mixes a lot of concerns, and how about a pipeline that
validates the input, writes to a source, mails a result to the user and
generates an output message, where the mail is optional and can be

>Wouldn't flow/pipeline and let you assemble them at need suffice?

I can not oversee the consequences of such a change. This would mean that a
pipeline consists of flow that glues together a number of
sub-pipelines/flows? Maybe.

My main problem is that in the current Cocoon version, a pipeline once setup
can hardly be influenced by some kind of control flow. And that mixing EJB
input / output, application exceptions and SAX makes things even more
complicated. Or should I say a challenge :-) 

I haven't seen a clean solution that made me jump in the air (which the
pipeline concept and the block concept did when I realised what they meant).
I'm hoping you have some more up your sleeve ;-)


>Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message