Sylvain Wallez wrote:
> >
> >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 !
>
Yes, maybe.
> >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.
>
Hmm, not exactly - they are not optional - they are defined by the used
component. If you read the docs, you know which ones this component
returns. They are not directly visible - yes, that's true.
If you simply use a variable in a programming language you don't know
which one is used, either. You have to carefully scan the code and
the same applies to the sitemap where you have to scan the sitemap
(and the docs).
And you still can use {../../../../37} - no problem.
In the last months I saw many cocoon users complaining or even
getting stuck into this area. They forgot a ../ here and so on.
> >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 :-/
>
Sniff....ok, let's continue the discussions tomorrow :)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
