cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT]: Unifying input modules and global parameters
Date Thu, 27 Jun 2002 12:40:41 GMT
Carsten Ziegeler wrote:

>In the latest CVS of 2.1, I think we have two overlapping 
>concepts: the global parameters and the input modules.
>Perhaps we could merge the global parameters somehow into
>the input modules and then remove the global parameters
>as a separate concept again.
>Current State
>Currently, the global parameters are declared in the
>map:pipelines section of a sitemap and the scope
>is the map:pipeline sections.
>So, if you want to refer to a global parameter, for
>example named "skin", you have to use
>{skin}, or {../skin} etc. depending on the depth of
>your statement in the map:pipeline section.

I didn't knew this already existed, but thought of that while 
implementing module-defined parameters. Basically, the idea is that 
global sitemap parameters can be accessed throught the root of the 
variable tree, i.e. {/skin}.

>- If you refer to a global parameter, you have to
>  precisly specify the path (= count the ../)

With the "/"-rooted syntax, this problem disappears.

>- global parameters are not inherited/available to 
>  sub-sitemaps

I'm not sure if it's good for them to be automatically inherited. I 
suggested to add <map:parameters> to <map:mount> to achieve a behaviour 
similar to <xsl:param> (see

>- Configuration directly in the sitemap
>The input modules are completly defined in the cocoon.xconf,
>they can be used inside every sitemap by first choosing
>the input module and then the key, like {request:parametername}.
>- Simple use
>- Single configured values are available in all sitemaps
>- Configuration is not in the sitemap, but in the cocoon.xconf
>Proposed Solution
>Make one input module sitemap configurable, like the 
>authentication manager. This means a (global) input module is
>defined in the cocoon.xconf, but can be additionally configured
>in the sitemap.
>A subsitemap inherits this configuration from it's parent sitemap
>and can add own key/value pairs, so this would look like this:
>  <map:component-configurations>
>    <global-input-module>
>      <skin>some-value</skin>
>      ...
>    </global-input-module>
>  </map:component-configurations>
>So, the key {global:skin} is available in this sitemap and in
>all sub-sitemaps.
>Comments? Suggestions?

Is this special handing of a particular global inputmodule still needed 
with "/"-rooted variables and <map:parameters> as proposed above ?

Also, a few days ago, you have forbidden someone to add additional 
components in <map:components>, but since it _does_ work (only with the 
TreeProcessor, just like InputModules), wouldn't it be simpler to add 
<input-modules> in <map:components> to locally redefine/augment the set 
of input modules defined in cocoon.xconf ? Note that allowing this would 
be a first step towards a separate xconf per sitemap, and then cocoon 


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message