cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
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 
>> blocks.properties to local.blocks.properties 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 
> "exclude.block.xyz" rather than its value, is that right?

I guess this was "once upon a time". The current version even allows 
exclude.block.xyz=false and handles this the same way as the property 
would not be there because of the
<condition>
   <istrue/>
</condition>
construct. So it's more a bad documentation at the moment. Quote from 
blocks.properties: "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, "include.block.xyz" makes more sense.

We can do it with changed documentation using exclude.block.xyz=false. 
As local.blocks.properties is loaded before blocks.properties and 
properties can not be reset, this would work.

I personally prefer the other way around: include.block.xyz - including 
the consequences of forcing users to recopy the blocks.properties 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.

Joerg

Mime
View raw message