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: [Vote] notation of blocks selection properties
Date Fri, 02 Apr 2004 13:15:23 GMT
Tim Larson <tim <at> keow.org> writes:

> > >  include=true   ==  exclude=false
> > 
> > No.
> > 
> > >  include=false  ==  exclude=true
> > 
> > Yes.
> <snip/>
> 
> I admit that I did not completely follow your explanation, but
> is the problem that the statement equalities listed above are
> not correct,

Why should they be not correct? No, it's indeed only implementation/Ant.

> or that even if they are correct that they still
> would not provide compatibility, or lastly only that it cannot
> be implemented via Ant?  If it is only this last problem, then
> surely there is some other way to make Ant fit the need.

We have at the moment:

exclude.block.blockname=true
#exclude.block.blockname=true
and
exclude.block.blockname=false
would also work. But the latter only because of the mapping of
exclude.block.blockname to unless.exclude.block.blockname through this construct:

<condition property="unless.exclude.block.blockname">
  <istrue value="${exclude.block.blockname}"/>
</condition>

So unless.exclude.block.blockname is *only* set if exclude.block.blockname is
true/yes/on. Otherwise it is *not* set (to false or similar).

Ant can execute targets in dependency on set properties:

<target name="blockname-compile" unless="unless.exclude.block.blockname"/>

means: execute this target if the property unless.exclude.block.blockname is
*not* set. Setting the property to false would let the target be executed.

What I wanted to do:

include.block.blockname=true|false

mapped via

<condition property="exclude.block.blockname">
  <not>
    <istrue value="${include.block.blockname}"/>
  </not>
</condition>

and use unless="exclude.block.blockname".

This solution would be backwards compatible except for the case
exclude.block.blockname=false (or any value != true/yes/on) as this would not
lead to expected behaviour. The block would be excluded independent on the value
of this property.

Now when writing the answer to your first statement equalities mail I had the
idea that we could use double mapping:

<!-- additional wrapper for usage of include.block.blockname -->
<condition property="exclude.block.blockname">
  <not>
    <istrue value="${include.block.blockname}"/>
  </not>
</condition>
<!-- like before -->
<condition property="unless.exclude.block.blockname">
  <istrue value="${exclude.block.blockname}"/>
</condition>

As the default settings (blocks.properties) use include.block.blockname, in
local.blocks.properties exclude.block.blockname can be used with arbitrary value
because it's mapped again. This would lead to complete backwards compatibility
and fulfill your both statement equalities. The more I think about it the more I
like the latter solution though there is a bit more code.

It was a long mail, but I hope it's more clear now.

Joerg


Mime
View raw message