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:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
