cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: [Vote] notation of blocks selection properties
Date Fri, 02 Apr 2004 13:33:04 GMT
Joerg,

How hard would it be to switch to having:

build stable
or
build unstable

instead of build webapp?

That would enable someone to choose right up front, without having to do 
any file editing.

Regards, Upayavira

Joerg Heinicke wrote:

>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