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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
