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}"/>
</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.
All that would be needed, is a change to:
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.java'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.
--
Ilya
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
>>newbies??
>>
>>The only nice proposal I found was made by Ilya A. Kriveshko:
>>http://www.mail-archive.com/cocoon-dev@xml.apache.org/msg22477.html.
>>
>>Regards,
>>
>>Joerg
>>
>>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
>>>
>>>cheers
>>>--
>>>Torsten
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, email: [EMAIL PROTECTED]
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
