On Wed, 02 Mar 2005 18:14:56 +0100, Daniel Fagerstrom <[EMAIL PROTECTED]> wrote: > Peter Hunsberger wrote: > > >On Tue, 01 Mar 2005 11:33:32 +0100, Daniel Fagerstrom > ><[EMAIL PROTECTED]> 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
