cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [announce] Extended sitemap variable substitution syntax
Date Tue, 25 Jun 2002 08:13:17 GMT
On Tuesday 25 June 2002 09:40, Piroumian Konstantin wrote:
> > Hi team,
> >
> > The extended sitemap variable substitution syntax based on
> > InputModules
> > is available in HEAD.


> > Sitemap variables can now be prefixed by the name of an InputModule.
> > This means for example that "{request:foo}" will evaluate to
> > the value
> > of the "foo" request parameter or that "{session:myAttr}"
> > will evaluate
> > to the value of the "myAttr" session attribute.
> To the value of myAttr.toString(), am I right?
> Don't you think that next thing that will be needed is to get a value in
> some other way, e.g. using an XPath with DOM objects, e.g.:
> {session:myDOM#/root/errors/error[@id='myfield']}
> ? So, the quantity of input modules will start to grow as actions' did.

hm.... interesting idea ;-)


> > This new feature means that InputModules will be more widely
> > used, and
> > therefore I'd like to propose some changes in the names they
> > have in the
> > current cocoon.xconf to more meaningfull ones :
> > - "request-param" instead of "request" for request parameters,
> > - "request-header" instead of "header" for request headers,
> > - "request-attr" instead of "attribute" for request attributes,
> > - "session-attr" instead of "session" for session attributes.
> I'd also add:
>  "app-attr" for servlet (application) context attributes
>  "app-init-param" for servlet init params


> Hm...
> Won't it be better to have one parametrized InputModule, say for, "request"
> and use it to get all the needed data from the request, be it a param,
> attribute, header or maybe request URI, etc? The same for "app" module,
> that will be used to get: servlet context attributes, init params, context
> name, etc.?

hm... that sounds reasonable and will reduce the number modules dramatically. 

> I don't have a good idea on how the syntax can look like for this (maybe
> "request:param:/...", "request:attr:/", etc.)?

hm... if we'd go that far "request:getParameter(bla)" would probably the most 
straight forward syntax for those users. But sooner or later there will be 
requests asking for default values (if a parameter is not set) and we end up 
with a mini-scripting language. I doubt we want to encourage that... do we?

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

View raw message