cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ilya A. Kriveshko" <>
Subject Re: [Announcement] sitemap variables
Date Wed, 09 Oct 2002 21:27:13 GMT
Deeply respectable folks,

I already posted on a similar issue (w/o response, thus far) but maybe 
that discussion was already dead by then. However, since my last message 
is relevant to this issue as well, I am taking the liberty to re-post it 
in this thread too:

My previous post:

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}"/>

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.

All that would be needed, is a change to:'s 
invokeNodes() method to pre-pend the prefixes to the keys in the currentMap.

If my proposition is acceptable to you, I am even willing to implement 
it ('cause it's short and easy).

Sorry for intruding on your debate, but I have contributed my opinions 
and code here in the past and have been welcome then.

Antonio Gallardo Rivera wrote:

>Why try to reinvent the wheel?
>We already have XPath. Why use it? Because its like all computer related thing 
>teached us for years. Everybody know that ".." means parent.
>I agree with Joerg:
>"in my opinion the syntax {/////1} is really poor".
>I can add that nobody know this concept. Bus ask someone that never hear about 
>Cocoon and XPath: {../../../1}
>And quickly will respond: "3 level parents back"
>The syntax {///1} is ambigous. where we move? Into the childs or into the 
>parents. I think many people will guest that this is onto the chlids. That 
>will confuse this all thing more.
>Antonio Gallardo
>El Miércoles, 09 de Octubre de 2002 14:29, Joerg Heinicke escribió:
>>Hello Thorsten,
>>in my opinion the syntax {/////1} is really poor. Maybe it's only
>>because of my knowledge to XPath and file systems or protocols, but a
>>syntax like ////1 is not known anywhere. It's logical to use /1 to get
>>the root 1, but never for 1 level back. Who shell explain this to Cocoon
>>The only nice proposal I found was made by Ilya A. Kriveshko:
>>Torsten Curdt wrote:
>>>>>I also wanted to add support for going down the tree of results.
>>>>>but could not come up with a good syntax.
>>>>>{///1} - for 3 levels deeper
>>>>>{../../../1} - for 3 levels back
>>>>>But I am not quite sure if this really makes sense... FS?
>>>>I say {///1} (and sure it makes sense)
>>>>(but who cares what i say )
>>>be sure we care what users say...
>>>...but I'd like hear some more comments on this before I go for it
>>To unsubscribe, e-mail:
>>For additional commands, email:
>To unsubscribe, e-mail:
>For additional commands, email:

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

View raw message