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 19:01:56 GMT
On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
<danielf@nada.kth.se> wrote:
> 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.

Not sure what you're referring to here.  The base output modules seem
pretty straight forward though there seem versions with features I can
see no need for...

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

Don't really know.  At the time we wrote our code flow was pretty new
and I don't think any alternatives existed.  I haven't looked at
anything that's come along since (we'll be looking at upgrading to the
2.1.6 code sometime soon).

One thing that strikes me is that I don't see why you'd want to build
a DOM if you didn't have to. We pull a single value (sucess/faillure)
out of the SAX stream from the validation results as they fly by for
the flow side of things via a SAX filter. We also use the SAX stream
directly in the aggregated pipeline results (ie; like any other Cocoon
generator).  There's no real need for a DOM in this case, it's not
that the validation results are a huge amount of data or anything, but
I pretty well try and avoid building a DOM within Cocoon if I can...

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

 


-- 
Peter Hunsberger

Mime
View raw message