Michael Homeijer wrote:
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.
Good, I'm glad we reached an agreement here.
Most of the time when using cocoon I use a solution/workaround of having anI agree.
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.
It comes to mind that it should be the flowscript layer to handle those application-level exception out of an executed pipeline... or maybe not... hmmm, what do you think about this?
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.
Yep.
Since you agreed that pipelines aren't necessarely asymmetric, why do you need to specify 'input pipelines' above?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".
Wouldn't flow/pipeline and let you assemble them at need suffice?
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
