Hi!
I've implemented as promised input modules for accessing Request and Session
object properties from sitemap using XPath expressions, e.g.:
value="{request:userPrincipal/name}"
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:
http://localhost:8080/cocoon/samples/modules/
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.
Regards,
Konstantin
From: "Christian Haul" <[EMAIL PROTECTED]>
> 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
input
> > modules and found out that there is no input module for request
properties
> > (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
like
> > to propose to change the names for modules as below:
> >
> > 1. request - for RequestModule (I volunteer to implement it), to
provide
> > 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
properties.
> >
> > 7. application-attr - web application context attributes (servlet
> > context attributes)
> >
> > If we agree on this, I am volunteering to implement the RequestModule
(or
> > maybe RequestPropertiesModule) and if I have time then I'll also
implement
> > the modules related to session and application.
>
> Konstantin, this is a good idea and it would really improve InputModules a
lot.
> 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
me
> > that having passive modules (that implement only the 'getter'
functionality)
> > 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
that
> > 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
replacing
> > the LocaleAction with an input module, but I am in doubts if I should
set
> > user's locale in an input module? This involves setting a request or
session
> > attribute and/or a cookie.
> > </question>
>
> There's the OutputModule interface for setting values. A class could
implement
> both interfaces, but one would have two instances floating around. As
Sylvain
> 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
> [EMAIL PROTECTED]
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
