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.
excellent!
> > 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 ;-)
<snip/>
> > 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
cool!
> 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?
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
