cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] A Unified Environment Model?
Date Wed, 02 Mar 2005 19:51:13 GMT
Peter Hunsberger wrote:

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



Mime
View raw message