cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [Announcement] sitemap variables
Date Thu, 10 Oct 2002 06:02:23 GMT
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:ilya@kaon.com]
> Sent: Wednesday, October 09, 2002 11:27 PM
> To: cocoon-dev@xml.apache.org
> 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: cocoon-dev-unsubscribe@xml.apache.org
> >>For additional commands, email: cocoon-dev-help@xml.apache.org
> >>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> >For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message