cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Startable components
Date Tue, 18 Oct 2005 10:17:14 GMT
Bart Molenkamp wrote:
> I understand that both the configuration and the marker interface
> options are working, great. But I'm still not satisfied by your answer,
> sorry. My points:
> 1. I don't see that much difference between a developer and a
> configuration writer.

That's because you are a developer :-)

> Knowing the configuration settings of a component
> can also require (deep) knowledge about the implementation. And,
> configuration writers don't need to write the configuration from
> scratch, the already configured defaults are sufficient.

The configuration settings require understanding of the implementation 
if there is no docs for it. Many components do have some docs, and 
hopefully more and more will have in the future.

> 2. To configure a component, knowledge about it is required anyways.
> Looking at the configuration of CForms for example, there is quite some
> configuration, but not much for a regular user to change (all those
> builders etc - which I think is great that it is configurable). For
> regular Cocoon users, I think the default configuration that comes with
> a Cocoon build is sufficient in many, many cases (again, I don't think
> users write configuration files from scratch).

Most components have sensible builtin defaults, meaning they often can 
work without specific configuration. This is different from Spring where 
you have to describe everything. Cultural difference that explains both 
why Avalon is intrusive and why Cocoon components should "just work" 
except when you want to give them some specific instructions through 
their configuration.

> 3. There is a dependency on Avalon, a project that is closed, and this
> project wanting to move away from it (at least that is my impression).
> This doesn't encourage me to use the Avalon interfaces, it rather
> "scares" me to use them. Configuration gives me much more feeling that
> I'm not tied in to Avalon, and can migrate to another container with
> less effort.

False impression! The preload="true" thing is very specific to the ECM+, 
Cocoon's own implementation of Avalon container interfaces. You are very 
unlikely to see it on any other container!!!

> 4. The way I learned to write components is by looking at the sources of
> Cocoon. So shouldn't the code show how it is supposed to be (for new
> and/or recently updated components), instead of how it always was?

Again, many people use Cocoon without having ever opened any one of its 
source files. And these are the people that will be the less likely to 
find that they forgot or accidentally removed a preload="true" somewhere...


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message