cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
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}.

>Disadvantages:
>- 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 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102267914817420&w=2)

>Advantage:
>- 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}.
>
>Advantage:
>- Simple use
>- Single configured values are available in all sitemaps
>
>Disadvantage:
>- 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:pipelines>
>  <map:component-configurations>
>    <global-input-module>
>      <skin>some-value</skin>
>      ...
>    </global-input-module>
>  </map:component-configurations>
></map:pipelines>
>
>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 
blocks.

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message