Re: unstable blocks

[Joerg Heinicke <jo...@gmx.de>]

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

Re: unstable blocks

[Joerg Heinicke <jo...@gmx.de>]

Antonio Gallardo <agallardo <at> agssa.net> writes:

> It was never was as documented, because of the Ant properties nature,
> always was the posibility to set exclude.block.xyz=[false, true]:
> http://ant.apache.org/manual/CoreTasks/property.html

Not quite true. @unless and @if (this is were the exclude (mapped to
unless.exclude) properties are used) don't look on the value of the property,
only the existence. This is why it only works because of the usage of
<condition>
  <istrue/>
</condition>

Joerg

Re: unstable blocks

[Antonio Gallardo <ag...@agssa.net>]

Joerg Heinicke dijo:
> On 30.03.2004 11:44, Bertrand Delacretaz wrote:
>> 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."

It was never was as documented, because of the Ant properties nature,
always was the posibility to set exclude.block.xyz=[false, true]:
http://ant.apache.org/manual/CoreTasks/property.html

I meet this first while imported the OJB block and I don't wanted to
compile it by default.

>>> ...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.

+1 for Change only the documentation (to "use true|false") because in fact
this is the way t currently works.

+0 for additionally the property names from exclude to include. It is just
a matter of name. The question here is what is easier: define included or
excluded blocks. In my case, I have more excluded blocks than included
ones.

Best Regards,

Antonio Gallardo.

Re: unstable blocks

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Le 31 mars 04, à 23:46, Joerg Heinicke a écrit :
> ...WDYT? Change only the documentation (to "use true|false") or 
> additionally the property names from exclude to include....

I'm for changing from exclude to include, but you might want to ask for 
a [VOTE], or at least a quick vote as this is a kind of "interface 
change".

-Bertrand