You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/03/30 11:19:25 UTC
unstable blocks (was: [VOTE] Move javaflow into scratchpad)
On 30.03.2004 10:33, Bertrand Delacretaz wrote:
> I like the idea, and it's easy to do as blocks.properties are generated
> from gump.xml.
Indeed.
> Problem is, this means shipping with many blocks disabled. I think this
> would warrant a notice at the top of the "blocks with samples" page,
> something like "see blocks.properties for a list of all available blocks".
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.
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 as this property is not
used directly in blocks-build.xml, but mapped to a property
unless.exclude.block.{blockname} at the moment:
<condition property="unless.exclude.block.fop">
<istrue value="${exclude.block.fop}"/>
</condition>
Doing the mapping in another should not be impossible, allows us to use
the more intuitive notation proposed above and removes the need for
adding blocks.properties at all.
Joerg
Re: unstable blocks
Posted by 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
Posted by 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
Posted by 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
Re: unstable blocks
Posted by 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 (was: [VOTE] Move javaflow into scratchpad)
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 30 mars 04, à 11:19, Joerg Heinicke a écrit :
> ...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?
> ...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.
-Bertrand