Carsten Ziegeler wrote:
>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.
>
Carsten,
Yes, I also seen users stuck there. But the problem is that this sitemap
concept is not documented (at least, I failed to find proper doc).
User's problems will go away as soon as somebody with english writing
skill will put together something better then
http://xml.apache.org/cocoon/faq/faq-sitemap.html#faq-7 and in more
visible place.
Vadim
>>>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]
