cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] A Unified Environment Model?
Date Wed, 02 Mar 2005 17:14:56 GMT
Peter Hunsberger wrote:

>On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom
><> wrote:
>>Gregor J. Rothfuss wrote:
>>>Daniel Fagerstrom wrote:
>>>>As discussed in various threads we need a common environment model
>>>>for flow, templating (both with flow and non-flow input). And it will
>>>>also make Cocoon easier to learn if the environment part of FOM (let
>>>>us call it OM) and the sitemap environment model, i.e. input modules
>>>>(IMs) are put together in some way.
>>>it would make sense to also look at whether output modules still make
>>>sense, and if yes, how to support those. they look like a hack to me,
>>>but maybe i'm missing something.
>>IIRC they where designed to be used for XSP actions and in DB contexts,
>>but I have not used them for such things and for use together with flow
>>they seem unnecesary complicated for my taste. So I don't know if output
>>modules make sense anymore either.
>I think the prototypical scenario is Web services where you want to
>invoke a Cocoon pipeline and capture the output for use in some other
It was designed for DB applications, it contains some kind of 
transaction processing with rolbacks. I'm not questioning that something 
like input/output modules can be usefull. My main point is that I find 
them over enginered and have to much features for the kind of needs we 
IMHO have today.

>In our case we use output modules for Schematron validation via flow. 
>A flow process fires off an internal  Cocoon pipeline that dynamically
>builds a Schematron template to validate form input and captures the
>results into the request-attr output module.
Does the output module buy you anything compared to have an 
pipelineUtil.processToDOM and then asign the request attribute with the 
resulting DOM directly via FOM?

>  This is then
>subsequently picked up in the regular pipeline as input to the
>pipeline via aggregation from an input module. The results of the
>validation can be checked both in the flow (to determine flow path as
>a result of validation) and shown in the form if there where errors.
I wrote about how to make it easier to put together web services in 
Cocoon a while ago, in the end of

We will need to refactor the environment handling for VPCs and blocks 
anyway, I think we should take better web service orchestration into 
account also when we do that.


View raw message