cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <peter.hunsber...@gmail.com>
Subject Re: [RT] A Unified Environment Model?
Date Wed, 02 Mar 2005 15:07:41 GMT
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.

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.  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.

-- 
Peter Hunsberger

Mime
View raw message