At 05:06 30/6/00 +0200, you wrote:
>>>>>> "PD" == Peter Donald <[EMAIL PROTECTED]> writes:
>
> >> Maybe I've misunderstood your proposal.
>
> PD> Nope. Your right there.
>
>I was afraid I would be.
>
>For those "other tasks", those not extending AbstractTasklet, would
>you want scripts to be able to work on them - setting/getting
>attributes? Or would you want the user to be aware that there are two
>kinds of tasks, those that you could manipulate and those you could
>not?
Well when we move to deferred tasks (if we do) then there is going to have
to be a rethinking on how scripting interacts with properties etc anyway.
So this point may be moot if we move to proxies. Depends on the
implementation strategy. As for scripts I have specifically created some of
these tasks so that I could do stuff declaratively rather than procedurally
so I am not sure scripting would be appropriate to them - Not sure.
Something to think about anyway.
>if (dir == null) {
> throw new BuildException("dir attribute must be set on filesets");
>}
>
>in whatever represents filesets.
>
>This is exactly the kind of validation you want to put into
>AbstractTasklet, isn't it?
yep
>I'm not saying that a Validator class of some kind would be useless,
>quite the opposite. But put it to good use for the nested elements as
>well.
oh okay yup. I was thinking you mean all elements including targets etc :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
