Stefan Bodewig wrote:
On 22 Nov 2004, <[EMAIL PROTECTED]> wrote:
Index: ConditionAndTask.java
protected abstract boolean evaluate();
/**
* This method evaluates the condition. It calls evaluate in
* the derived class. It sets the property if a property is
* present and if the evaluate returns true. @return true if
* the condition passes, false otherwise. */
public boolean eval() {
if (evaluate()) {
if (property != null) {
getProject().setNewProperty(property, value);
}
return true;
} else {
return false;
}
}
Why do you introduce an additional abstract method?
Wouldn't it be easier to place the logic of your eval into execute()
directly and force subclasses to implement eval() just as they'd do as
plain conditions anyway?
I wanted to separate the property handing logic from the conditon code.
I'm a bit uncomfortable with ConditionAndTask in general, but that's a separate issue from the above.
The other issue simply is: why do we need it?
What's wrong with
<condition property="..." ...> <foo/> </condition>
Mmm..., you do have a point... This does make more sense..
I will make the changes. Peter
Why do we need an additional <foo> task? <available> and the other tasks that can be conditions as well have simply been there before <condition> was added, I don't really see why we should add more property setting tasks.
Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
