How about prefixing of retuned parameters' names? Here's what I mean:
<map:match pattern="*-*" param-prefix="mtch1">
<!-- matcher returns parameters: '1' and '2', which are renamed to
'mtch1:1' and 'mtch1:2' -->
<map:act type="my-action" param-prefix="act1">
<!-- my-action alsoreturns parameters: '1' and '2', which are
renamed to 'act1:1' and 'act1:2' -->
<map:generate type="serverpages" src="{mtch:1}.xsp">
<map:parameter name="display" value="{mtch1:2}"/>
<map:parameter name="param1" value="{act1:1}"/>
<map:parameter name="param2" value="{act1:2}"/>
</map:generate>
</map:act>
</map:match>
Obviously, the exact syntax (i.e. 'prefix:name') is not crucial here.
The sitemap components themselves would not be aware of the prefix, and
would simply return a Map with "1" and "2".
The prefix would be prepended to all the parameter names in that Map by
whatever code is interpreting/executing the sitemap (?)
This way one can always control the visibility of the parameters in
nested elements explicitly by choosing a unique prefix or a matching
prefix. This would also not require any changes to the existing users'
sitemaps, since w/o prefixes everything would work as it does now.
Sorry for intruding on your debate, but I have contributed my opinions
and code here in the past and have been welcome then.
--
Ilya
Vadim Gritsenko wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
