cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Configuration of TreeBuilder
Date Sun, 05 May 2002 12:48:05 GMT
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> >
> >
> > What about using XInclude, which, through XPointer, would allow to
> > insert in cocoon.xconf elements from an external file that would contain
> > only those parts that we allow the sysadmin to change ?
> >
> > I already used this in Cocoon1 days to insert configuration values from
> > a central application config file inside XSP pages, and it worked like a
> > charm !
> >
> I totally agree, that the cocoon.xconf is too big, no doubt.
> But I hear very often complains about too many configuration files for
> Cocoon (web.xml, logkit.xconf, cocoon.xconf, sitemap.xmap etc). By
> segmenting
> this further, we will get a smaller cocoon.xconf, but it will not get
> less complicated, I fear.

I agree. Look at what happened for Apache HTTPD: they started with
httpd.conf, then became too big and had other two files, then people
didn't understand where the directives went, so they allowed directives
to go everywhere, then they glued everything back into one big

I don't think that cocoon.xconf is too big: it's just too messy. I mean,
there are several different level of configurations there and some (like
the default XSP taglibs) cannot be considered configurations if they are
a contract that people assume when they use XSP.

(the same could be said for the sitemap component configuration in the
root sitemap.xmap).

This is the problem with heavily component-based architectures:
programmability and configuration have a very thin line.

> Using an XML editor (or a tool) for the cocoon.xconf makes the usage in
> my eyes much easier than splitting it into many parts. With an XML editor
> you can for example only display the top-level component nodes and simply
> select the component you want to change. So, it's still very simple. If
> you have several files, nearly all tools fail.
> And the configuration is "maintained" by Avalon, so if we decide to build
> a solution this should rather happend in Avalon than in Cocoon.

If Cocoon Blocks contain their own configurations, wouldn't that solve
the issues?

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message