Carsten Ziegeler wrote:
>The more I think about this approach, the more I like it.
>But, I see some problems here:
>- First one is of course name clashes - I should not define
> a param-prefix which is either already used or already
> defined by an input module.
>
My experience with Cocoon is limited only to things that I actually had
to use (Clearly, I belong on the cocoon-users list.) Therefore, I wasn't
aware of InputModules using the ':' syntax. As I said, the separator for
the prefix is non-essential. It could be a java-esque '.', a '-', an
XPath-esque '{//prefix/1}' or even something like '{prefix[1]}'.
Whatever syntax doesn't clash with the existing functionality if that's
something to be avoided.
Scoping is still obviously involved, so you only need to care about
clashing with the parent nodes' prefixes.
>- It's a little bit too verbose, which means I have to type
> a lot to get it working.
>
However:
1) You don't have to use it until you need to use it.
2) It's only as verbose as you choose. I like verbose, so that's how it
would be for me.
3) {../../../1} or {////1} is also somewhat verbose, but is not nearly
as readable. You have to look over larger section of the sitemap to see
where the parameter is coming from, whereas with named prefixes, all you
have to do is search backward if it isn't clear just from the prefix.
>It came to my mind to simple use the "type" of the component
>as a prefix:
><map:match pattern="**">
> <map:generate src="{wildcard:1}"/>
>
>and I can then override this if I have the same component
>nested:
><map:match pattern="**" param-prefix="wildcard2">
> <map:generate src="{wildcard2:1}"/>
>
I just typed up a long paragraph disagreeing with this for
implementation reasons, but by the end of it I convinced myself that
it's actually a decent suggestion. So, there. :-)
If default prefixes are to be allowed, then it is not sufficient to
rename parameters in invokeNodes. The parameter resolution would have to
be amended as well to accept both prefixed and unprefixed names. I'm not
familiar with the code that resolves parameters. At least not for
another few minutes.
>Hmm, there still the possible name classes with input modules.
>Any idea?
>
See above: alternative prefixing syntax.
>And of course {1} and {../1} must still work.
>
Agree 100%.
>What do others think?
>
>Carsten
>
>
>
>>-----Original Message-----
>>From: Ilya A. Kriveshko [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, October 09, 2002 11:27 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: [Announcement] sitemap variables
>>
>>
>>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.AbstractParentProcessin
>>gNode.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]
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, email: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
