cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [Proposal]: Advanced Value Substitution
Date Tue, 08 Oct 2002 09:25:20 GMT
Carsten Ziegeler wrote:

>here is a simple proposal for an easier value substitution algorithm
>in the sitemap.
>Currently, if you nest actions and matchers you have to aware of
>the paths to get your information:
><match pattern="**">
>  <act type="anything">
>      <read src="{directory}/{../1}"/>
>  </act>
>This can get very complicated. When I first got contact with value
>substitution more than two years ago, I thought I could write:
><read src="{directory}/{1}"/>
>The two components use different keys, so there is no conflict and
>the values can be resolved.
>This is in accordence to usual programming languages where a
>variable is not only searched in the current scope but also
>in the parent scope:
>   int i;
>   {
>      int x;
>      i = 5;
>   }
>Only if you have conflicts, which means you define a variable with
>the same name in the inner block and want to use a variable with
>the same name of an outer block you have to define the complete
>So, keeping this short, I propose to change the search algorithm
>for value substitution:
>If a key is not found in the inner block, the search is continued
>up the chain. 

Crawling up the chain can be very expensive !

>So in the above example {1} is first searched in the values
>delivered by the action - not found there - and then searched
>in the values by the matcher.

Your above example, even if it seems nice at first, leads to some 
predictability problems : how do you know which {1} will be used ? What 
if several components in the stack return a {1} but with a different 
meaning ?

In a programming language, a local variable is *written* in the code, 
and you know which one you are using, even if hiding variables is often 
considered as a bad practice - if allowed by compilers. In the sitemap, 
returned variables are optional and their names aren't visible.

>The old path syntax is untouched - so no compatibility problems
>but easier handling.
>What do you think?

Sorry Carsten, this is a day where we don't agree :-/


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message