cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [RT] A Unified Environment Model?
Date Wed, 02 Mar 2005 20:05:09 GMT
On Wed, 02 Mar 2005 20:51:13 +0100, Daniel Fagerstrom
<> wrote:
> Peter Hunsberger wrote:
> >On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom
> ><> wrote:
> >
> >
> >>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
> >>>>>>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
> >>>>>>us call it OM) and the sitemap environment model, i.e. input
> >>>>>>(IMs) are put together in some way.
> >>>>>>
> >>>>>>
> >>>>>it would make sense to also look at whether output modules still
> >>>>>sense, and if yes, how to support those. they look like a hack to
> >>>>>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...
> >
> Take a look at the interface,
> it contains a commit and a rollback method and all methods take runtime
> configuration objects. It might have been usefull for the database
> applications they where designed for,
> but I wonder if they are used much for such applications anymore.

Yuck.  Don't know.  At the very least we could make two versions of
the interface and have the simpler version (without the
rollback/commit) as the normal base...

> In the original message in this thread I discussed a unified script
> object model. Several people have proposed that such a model should be
> like FOM but built from modules. For this specific use case I find the
> current input/output modules unecessary complicated.

Sure, the interface isn't  100%, but thhe concept seems pretty much correct?

> >>>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.
> >
> I don't want to do anything at all in your applications ;) From your
> description I got the impression that you got XML output that you wanted
> to put in a request attribute. For that, using the XModuleSource to
> write to an request-attr output module seemed to be an reasonable
> assumption about why you used an output module at all. But from your
> description I fail to figure out from where you use your output module.

You've got it more-or-less correct, but we build a buffered SAX
stream, not a DOM.  We don't really use a request-attr, but it's
simpler to explain things in those terms then using proprietary module
descriptions (even if they are just wrappers around existing Cocoon
functionality) .For this discussion I should have been more precise
since it appears you're digging into the guts of what's really

> > 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...
> >
> The reference I gave below is about how to extend the envronment
> handling in Cocoon so that it is easy to glue together various "web
> service" pipelines so that they talk to each other without needing to
> buffer any intermediate results.
> >>> 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.
> >>

Peter Hunsberger

View raw message