Re: Why a Selector is evaluated at beginning of pipeline?

[Geoff Howard <co...@leverageweb.com>]

Sebastian Klamar wrote:
> * Sebastian Klamar [2004-01-10 18:49 +0100] wrote:
> 
>><map:transformer type="bla"/>
>><!-- here the session attribute is generated -->
>><map:transformer type="myexaminer"/>
>><map:select type="session-attribute">
>>  <map:parameter name="attribute-name" value="foo"/>
>>  <map:when test="okay">
>>    <map:transform type="bar"/>
>>  <map:otherwise>
>>    <map:transform type="bar2"/>
>>  <map:otherwise>
>><map:select>
> 
> 
> Given my example, is it right that the selector is evaluated at the
> beginning of the pipeline (after the match when the pipeline is
> constructed), that means BEFORE bla and myexaminor transformer?  Why
> that?

Yes, first any matchers/selectors (they can be infinitely nested) are 
"executed" or better "evaluated", then the 
Generator->Transformer*->Serializer pipeline begins processing.  So, 
your session attribute selector cannot rely on any side effects of the 
generator and transformers which preceed it when reading the sitemap.  I 
think I've already given the answers about why but once again, a 
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.

Geoff


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

Re: Why a Selector is evaluated at beginning of pipeline?

[Sebastian Klamar <se...@tux.wh17.tu-dresden.de>]

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).


      Sebastian

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

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