On 25.Jun.2002 -- 11:40 AM, Piroumian Konstantin wrote:
> > 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?
Yes, since sitemap parameters are strings.
> 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.
Oh, you could build new ones around existing ones. I like to call them
"meta" mdoules because they work on the content provided by another
one. There are already a few of them, constructing collection types,
message digests and default values. Still planing for a row type
module but currently don't really need it myself ;-)
If you want to use XPath expressions, create a meta module for that
and you can use it on any other one.
> > 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.?
Sure. It's just that these modules started as a drop-in replacement
(more or less) for accessing these values directly. It's rather
trivial to build such a module you envision. Go ahead :-)
> I don't have a good idea on how the syntax can look like for this (maybe
> "request:param:/...", "request:attr:/", etc.)?
Actually, this has to viewn without thinking about the sitemap per se
since (input) modules are used at different places. Thus we need to
focus on the string after the module name.
Given such a all-in-one-request-module, using the attribute name
"param:name-of-parameter" or "param/name-of-parameter" seem OK. I
prefer the second form, since I would use the "name:" syntax for above
mentioned meta modules to specify the module to use.
Thus your example would result in (sitemap.xmap)
<map:parameter name="foo" value="{all-request:param/foo}"/>
or (database.xml)
<value name="foo" type="int">
<mode type="all" name="all-request" parameter="param/foo"/>
</value>
or (declaration for a matcher)
<map:matchers>
<map:matcher logger="sitemap.matcher.modular.cached" name="foo-matcher"
src="org.apache.cocoon.matching.modular.CachingWildcardMatcher">
<input-module name="all-request"/>
<parameter-name>param/foo</parameter-name>
</map:matcher>
</map:matchers>
or (depending on the configuration understood by the module)
<map:matchers>
<map:matcher logger="sitemap.matcher.modular.cached" name="foo-matcher"
src="org.apache.cocoon.matching.modular.CachingWildcardMatcher">
<input-module name="all-request">
<parameter>param/foo</parameter>
</input-module>
</map:matcher>
</map:matchers>
or ...
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]
