cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
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
><danielf@nada.kth.se> 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
>pipeline.
>
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 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110833663225048&w=2.

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.

/Daniel



Mime
View raw message