cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Homeijer <M.Homei...@devote.nl>
Subject RE: [RT] Input Pipelines (long)
Date Mon, 30 Dec 2002 14:42:43 GMT
Hi,

I think your comment is right. It's not the (a)symmetry that's the problem,
it's the "glue" that connects the input to the output thats missing or
implicitly available.

Most of the time when using cocoon I use a solution/workaround of having an
aggregation of an "input" pipeline (for instance writing a resource in an
xml database) and the "output" pipeline (showing the new list of resources
in the xml database). Most of the time the "logic" of the pipeline, ie.
deciding if anything went wrong, ends up in xsl.

Because of the way map:handle-errors works (ie. you loose context
information etc.) I don't think it should be used to check application
logic/exceptions (for instance when a resource allready exists), but only
system execeptions. 

Another way of implementing the input part (and mixing the flow part in it)
is bij coding actions. This doesn't allways work out right as well. Some
applications I build with cocoon contain far to many specific actions
handling input and flow, and actions are not very good at handling xml / sax
input.

A construction of "pipeline input - flow - pipeline output" should solve
most of these cases, but I think the real "puzzle" will be how to fit this
in with the allready existing "pipeline setup"/"pipeline execution stages".

HTH,
Michael

> Nicola Ken Barozzi wrote:
(*)
Actually, the input pipelines discussion, as I understood it, is simply 
about the possibility of executing two pipelines per request, with the 
flow in the middle.

Cocoon2 is something that gets data from a Request, mainly the URL and 
some params, and generates a response with some xml stuff.

In web services though, the "Request", needs to be actually created from

an xml stream coming in.

Hence the talk about input pipelines, that would be those pipelines that

work on the request stream to generate the request that would drive the 
normal Cocoon process.

By separating the processing in two steps, it has been shown how we 
fulfill the need that is needed for selecting based on pipeline content 
by not doing it: first we process the xml with an input pipeline, create

an intermediate "Request", and then select based on that data.

This two stepped process made Cocoon seem asymmetric because now it 
cannot explicitly do it, and this two step thing seems more symmetric, 
etc etc etc.

>  4) I would like to see Environment abstract enough to work in a
Mailet 
> environment
> 
>  5) I would like this effort to be driven by real-life needs rather
than 
> purity and symmetry-driven architectural design (since we've seen that

> it often leads to very bad mistakes!)

Ok, wait for a new thread on this. Let's keep this thread for the real 
input pipeline discussion. (*)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message