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.
- It's a little bit too verbose, which means I have to type
a lot to get it working.
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}"/>
Hmm, there still the possible name classes with input modules.
Any idea?
And of course {1} and {../1} must still work.
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]
