Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4074B2AD.8090805@gmx.de>
Date: Thu, 08 Apr 2004 04:02:21 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: new blocks.properties way more painful to use
References: <4070899F.4080706@apache.org> <4071613A.3010006@leverageweb.com>
 <40717910.6050102@reverycodes.com>
In-Reply-To: <40717910.6050102@reverycodes.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 05.04.2004 17:19, Vadim Gritsenko wrote:

>>> in the past I was used to:
>>>
>>>  1) cp blocks.properties local.blocks.properties
>>>  2) vi local.blocks.properties
>>>  3) uncomment the blocks that I wanted to exclude
>>>
>>> Today, I have to go thru a bunch of include and change them from true 
>>> to false. Much more hassle than just uncommenting/commenting one line.
> 
> Ok, but it should be fairly easy to make "include" properties default to 
> "true" if nothing else is defined - then it (almost) solves an issue: 
> block.properties can contain comments only, and explain format. And 
> local.block.properties can define properties in any syntax - include or 
> exclude.

Thanks for the constructive idea. I have it working now the following 
way: internal.exclude set through include set through exclude property. 
In blocks.properties there are #include=false lines (except for the 
deprecated ones), blocks are included by default. This solution would 
bring back Stefano's uncommenting/commenting, but has one down side: the 
deprecated blocks excluded via include=false in blocks.properties can 
not be included by exclude=false (as it is possible now, backwards 
compatibility), but must be included by include=true.

WDYT? Commit?

Joerg