cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastian Klamar <>
Subject Re: Why a Selector is evaluated at beginning of pipeline?
Date Mon, 12 Jan 2004 10:52:39 GMT
Geoff, thanx for your answer.

* Geoff Howard [2004-01-12 03:56 +0100] wrote:
> pipeline generator->transormer->serializer is generally thought of
> like the "model" and "view" of the well known "MVC" pattern and
> therefore are not designed to be used as a "controller".  You have
> matchers, selectors, flow and actions for that.

But the controller, say matchers, selectors, flow and
actions, all they have no access to the model (except the new
PipelineUtil.processTo{DOM,SAX})!  So how to achieve control of flow?

This border results in workarounds like using xinclude to call the
next pipeline step (see Conal's first mail in the father thread) or
my currently preferred way: after the examination in a transformer, I
store the result via WriteDOMSessionTransformer, evaluate the status
in my flow script and afterwards call the next pipeline (using the
SessionAttributeGenerator).  This leads to a fragmentation of the
pipeline (as in my example) to 3 pipelines (one for processing till
evaluation, the other two for the map:when and map:otherwise) :-(  IMO
this is not a good solution.  You are right, flow script is destined
for controlling the flow, but I find my »wish example« better because
it better shows flow of data compared with the fragmentation into 3++
pipelines and using session attributes (or the new xmodule).


Die letzten Worte...
  des Ehemannes: "Ok!" (Auf die Frage: reparierst Du mal das Bügeleisen,
PGP Key: 0x1E727CE6 / 9085 48BD 8332 4BFC D80C  A6CF D162 20BB 1E72 7CE6

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

View raw message