cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [Vote] notation of blocks selection properties
Date Fri, 02 Apr 2004 13:15:23 GMT
Tim Larson <tim <at>> 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:

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}"/>

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:


mapped via

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

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">
    <istrue value="${include.block.blockname}"/>
<!-- like before -->
<condition property="unless.exclude.block.blockname">
  <istrue value="${exclude.block.blockname}"/>

As the default settings ( use include.block.blockname, in 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.


View raw message