Carsten Ziegeler wrote:
>Hi,
>
>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>
></match>
>
>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
>path.
>
>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
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
