Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <446998B8.2040107@apache.org>
Date: Tue, 16 May 2006 11:17:44 +0200
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [2.2] Configuration issues
References: <44696FFD.4030900@apache.org> <44699558.3060604@apache.org>
In-Reply-To: <44699558.3060604@apache.org>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> I'm currently wondering what the best way to configure 2.2 from a user
>> perspective is. We now have includes for xconfs and property
>> replacements which is great.
>> Now, each block comes with its own configuration files: all of them are
>> stored in the jar and on deployment some of these files are extracted:
>> so in the end there are roles files in the jar, xconf and property files
>> on the WEB-INF folder.
>> A user should never touch/change these files - so only way to customize
>> the settings is through properties. This requires that each and every
>> user configurable value must be replaced with a property! Now while this
>> approach is fine it has at least two problems:
>> 1. A huge number of properties which sooner or later will create a mess.
>> 2. This works only as long as the user wants to use the same
>> implementation for a component. Switching to an own implementation with
>> an own configuration is not possible.
>>
>> Any idea on how to solve this?
> 
> 
> Do you want to solve this for our first release? If we add the "beta" postfix, 
> adding some solution in the future isn't a problem. If you agree, I would like 
> to postpone the discussion for the time after first beta release.
I personally would like to have this in the first beta release, so we
can see if this is the right solution and eventually change this in the
next beta :)

> 
> @ your question: You probably don't like my answer but OSGi already solves this 
> kind of problem for us. Considering this I would only go for a very simple 
> solution so that user _can_ provide their own configuration files which are used 
> _instead_ of a block's configuration. For the usual needs (forms, template, 
> mail, apples, pdf block) this should be enough. Don't know about the portal 
> which is probably the use case you're thinking of.
The portal is no problem as you have your own config file anyway. I'm
more thinking of core or some blocks were you just add your own
components or override some, like adding your own validator to cforms
(which is no problem) or overriding the default email validator with
your own one (which is a problem).

How does OSGi solve this?

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/