cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <>
Subject RE: [RT] Input Pipelines (long)
Date Mon, 23 Dec 2002 16:34:46 GMT
Stefano Mazzocchi wrote:

<big snip/>

>> Here the generator reads an Excel document from the input stream that 
>> is submitted by the context, and translate it to some xml format. The 
>> serializer write its xml input in the file system. I reused the names 
>> generator and serializer partly because I didn't found any good names 
>> (deserializer is the inverse to serializer, but what is the inverse of 
>> a generator?)
> There is none, because the opposite of generation would be destruction 
> and you are definately *not* distructing something, but still *generate* 
> it. Where the data the generator uses comes from is *not* an 
> architectural concern and should not modify the component's name.

One could argue that the opposite of a generator is a "motor", or more
generally, a "utilizer"... 

<big snip/>

>> In Flowscripts
>> --------------
>> IIRC the discussion and examples of input for flowscripts this far has 
>> mainly dealed with request parameter based input. If we want to use 
>> flowscripts for describing e.g. web service flow, more advanced input 
>> handling is needed. IMO it would be an excelent SOC to use output 
>> pipelines for the presentation of the data used in the system, input 
>> pipelines for going from input to system data, java objects (or some 
>> other programming language) for describing business logic working on 
>> the data within the system, and flowscripts for connecting all this in 
>> an appropriate temporal order.
> A while ago, I proposed the addition of a new flowscript method that 
> would be something like this
>  invoquePipeline(uri, parameters, outputStream)
> that means that the flow will be calling the pipeline associated with 
> the given URI, but the serializer will write on the given outputStream.
> Since there were already too many irons in the fire, I wanted to see the 
> flowscript settle down before starting to push for this again, but your 
> RT brings back pressure on this concept and I think this is all we need 
> to remove the asymmetry from cocoon pipelines.

This seems to me to mostly close the circle: the "utilizer" being the

<big snip/>

To unsubscribe, e-mail:
For additional commands, email:

View raw message