ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [RFC] AbstractTasklet with extended functionality
Date Fri, 30 Jun 2000 14:16:23 GMT
>>>>> "PD" == Peter Donald <> writes:

 PD> well as I said you can keep the same design contract but now it
 PD> is handled by AbstractTasklet rather than by the parser.

But only for those extending AbstractTasklet. I thought your goal was
to get tasks without setters by extending your changed Task directly
and retrieve all the parameters from the TaskContext.

Maybe I've misunderstood your proposal.

 >> So a task that wants this validation would initialize
 >> AbstractTasklet with a list of acceptable properties, ...

 PD> As I said there is 0 cost if you don't want/need it.

Don't get me wrong, I'm just trying to fully understand what you are

 PD> true the functionality can be placed somewhere outside the class
 PD> but the particular rules are associated with the task (and
 PD> therefore I think they should be inside it).

One thing you miss here IMHO is that the same problems - setting of
attributes, creation of nested elements, validation of attributes -
holds for all the other objects corresponding to XML elements in the
buildfile as well. This is not a unique problem of tasks and all the
other "nested" objects don't share a parent class apart from Object,
at least I wouldn't want to restrict them to.

Therefore this functionality - if it can be generalized - should
better be placed outside of the Task hierarchy IMHO.


View raw message