cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT]: Unifying input modules and global parameters
Date Thu, 27 Jun 2002 12:54:09 GMT
Sylvain Wallez wrote:
> <snip> 
> >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 
I think inheritance makes sense, because all other things (=generators,
readers etc. ) are inherited, so why not global parameters. Adding
<map:parameters> to a <map:mount> is still a possible feature. Inheriting
global parameters does not prevent us from also doing it.

> <snip/>
> Is this special handing of a particular global inputmodule still needed 
> with "/"-rooted variables and <map:parameters> as proposed above ?
You have a special handling of a particular global inputmodule in contrast
to a special handling of so called global parameters. I don't know
what is better. But what makes IMHO sense, is the inheritance of
global parameters; I think someone already asked this some days ago.

> 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.
Wow, I didn't know I have the power to forbid someone something. I think
I don't have the power and I really don't want to have it. It's still
open source, so everyone can do what he wants (at least as long as he is
an accepted committer...).

And I'm still -1000 (or choose any number less than -1) on defining 
components in the sitemap. IMHO it is only possible by accident and
should be reverted. We really shouldn't allow this and patiently wait for
Stefano and Giacomo to present their blocks concept. If we allow
a <map:components> sections in the sitemap we could skip the cocoon.xconf.
But let's not get out of focus with this discussion, it's about
unifying input modules and global parameters.

So with your suggestion of a "/"-rooted syntax, we have another possibility
(if the parameters are inherited to a sub sitemap).


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

View raw message