cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: unstable blocks
Date Wed, 31 Mar 2004 21:46:56 GMT
On 30.03.2004 11:44, Bertrand Delacretaz wrote:

>> ...IMO having blocks disabled is not a problem. But the way 
>> re-enabling them is. It's no longer possible to tell the user "copy 
>> to and edit this one". I 
>> already had this issue when only including woody block after 
>> deprecation....
> Because the current detection is based on the presence of the 
> "" rather than its value, is that right?

I guess this was "once upon a time". The current version even allows and handles this the same way as the property 
would not be there because of the
construct. So it's more a bad documentation at the moment. Quote from "Remove blocks from your cocoon distribution by 
uncommenting the corresponding exclude property."

>> ...So when doing it - what it is a good thing - we have to change the 
>> build process in relation to blocks selection. Isn't it possible to 
>> switch to include.block.{blockname}={true|false} syntax...
> I'd be +1 on this, "" makes more sense.

We can do it with changed documentation using 
As is loaded before and 
properties can not be reset, this would work.

I personally prefer the other way around: - including 
the consequences of forcing users to recopy the and 
resetting their blocks selection.

I already have the include way working. It's backward compatible as long 
as the exclude=false is not already used.

WDYT? Change only the documentation (to "use true|false") or 
additionally the property names from exclude to include.


View raw message