Re: [RT] A Unified Environment Model?

[Daniel Fagerstrom]

Peter Hunsberger wrote:
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...
Take a look at the interface, 
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/components/modules/output/OutputModule.java?view=markup, 
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.

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.

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.

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