Re: Variables again

On Thu, May 1, 2008 at 6:14 PM, Norman Walsh <ndw@nwalsh.com> wrote:

> Bah. Our decision to allow p:variable only at the start of a compound
> step introduces another spurious group:
>
> <p:url-form-encode name="foo">
>  <p:with-param name="foo" select="'bar'"/>
>  <p:with-param name="bar" select="'baz'"/>
> </p:url-form-encode>
>
> <p:group>
>  <p:variable name="param" select=".">
>    <p:pipe step="foo" port="result"/>
>  </p:variable>
>
>  <p:string-replace match="whatever">
>    <p:input port="source">
>      ...
>    </p:input>
>    <p:option name="replace" select="concat(.,$param)"/>
>  </p:string-replace>
> </p:group>
>
> We made this rule so that we wouldn't have to deal with what happens
> when steps get reordered.
>
> I wonder if it would make sense instead to say:
>
> 1. Variables are attached to the step that follows them.
> 2. No forward references allowed in the (possibly reordered) sequence.


I'm sorry, I prefer to have an extra group that explictly  defines the scope
than another magic

And further more it doesn't solve this case

<p:variable name="foo" select"'bar1'"/>
<p:step name="order1">
  ...
  <p:option name="myoption" select="$foo"/>
</p:step>
<p:variable name="foo" select"'bar2'"/>
<p:step name="order2">
  ...
  <p:option name="myoption" select="$foo"/>
</p:step>

Depending on the dependency between those step (order1 >> order2 or order2
>> order1), I don't get how you know which value is used (even if there is
no forward reference)

Mohamed


-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €