cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <>
Subject Re: [Proposal] Input modules: access syntax and naming
Date Fri, 20 Sep 2002 23:22:26 GMT

I've implemented as promised input modules for accessing Request and Session
object properties from sitemap using XPath expressions, e.g.:
value="{request:session/id}", this is equivalent to value="{session:id}"

more complex expressions are also supported (e.g. with substring(),
string-length(), etc. functions). It is said that JXPath can get values from
Maps, but I couldn't get it working (I've tried to add getParameterMap()
method to Request implementation and get a value from the Map, but it didn't
work), probably, a newer version of JXPath is needed.

There is no need for such a module for the application Context object, cause
there is no any property which can be retrieved and have a meaning for the
usage in the sitemap.

A sample is also created. See it at:

Next step will be a generic input module for attributes. I am planning to
implement it in the same way it is done in JXPath: when an attribute value
is looked in the following order: page context (not applicable [yet] to
Cocoon), request, session, context. If scope is specified explicitely then
only the gived scope is used to get the attribute.

I think that with minor additions to JXPath (such as handling of
Enumerations and getters with a single String parameter) there will be no
need for special input modules for request headers and other enumerated and
key=value like data.


From: "Christian Haul" <>
> On 17.Sep.2002 -- 11:37 PM, Konstantin Piroumian wrote:
> > Hi folks!
> >
> >
> > 1) I've been recently trying to modernize the Forrest's sitemap using
> > modules and found out that there is no input module for request
> > (such
> > as context path, locale, query string,etc.). And the name used for the
> > request parameters module is misleading in this regard.
> >
> > I don't remember how the discussion about module names ended, but I'd
> > to propose to change the names for modules as below:
> >
> >     1. request - for RequestModule (I volunteer to implement it), to
> > access to context path, locale, uri, url, query string     and all other
> > properties of Request interface.
> >
> >     2. request-param - either of this for request parameters
> >
> >     3. request-attr - either of the for request attributes
> >
> >     4. session - for a module for Session properties, such as id, isNew,
> > etc.
> >
> >     5. session-attr - for session attributes
> >
> >     6. application - for a module for application context (Context)
> > properties, in case of web environment it's the ServletContext
> >
> >     7. application-attr - web application context attributes (servlet
> > context attributes)
> >
> > If we agree on this, I am volunteering to implement the RequestModule
> > maybe RequestPropertiesModule) and if I have time then I'll also
> > the modules related to session and application.
> Konstantin, this is a good idea and it would really improve InputModules a
> It would be great if you could find the time.
> > 2) Now a question:
> > <question>
> > First usage of input modules in Forrest for site skin selection showed
> > that having passive modules (that implement only the 'getter'
> > is not sufficient. In case of the skin when user chooses to use another
> > 'skin' he should pass a 'skin' request parameter. But the problem is
> > this parameter is not retained through the user's session and you should
> > either generate all the site links with this parameter or somehow set a
> > session attribute or a cookie
> >
> > The same is true for the user's locale. I've been thinking about
> > the LocaleAction with an input module, but I am in doubts if I should
> > user's locale in an input module? This involves setting a request or
> > attribute and/or a cookie.
> > </question>
> There's the OutputModule interface for setting values. A class could
> both interfaces, but one would have two instances floating around. As
> suggested, an action would be right I think.
> >
> > Any suggestion or a better solution is appreciated.
> Chris.
> --
> C h r i s t i a n       H a u l
>     fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

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

View raw message