ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [RFC] AbstractTasklet with extended functionality
Date Fri, 30 Jun 2000 14:25:29 GMT
At 04:16  30/6/00 +0200, you wrote:
> 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.

Nope. Your right there. I agree that in most (ie almost all) tasks this
simple behaviour is wanted/desired/acceptable but for some more complex
tasks it quickly becomes unmanageable fast - quite a few of my tasks have
in excess of 9 attributes. I already have to implement mutators, if I want
scripting I also have to implement accesors. Then I have to validate the
attributes and make sure each is correct format/value/has been set etc.
Anything that can reduce the amount of work I have to do to shoehorn my
tasks to the ant way is going to be good :P. What I have proposed keeps
identical functionality as we have now if task inherits from
AbstractTasklet but it is also free to implement it more efficiently if it
wants to.

> >> 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.

true :P but the validation I was wanting to use is very very specific and
not really general like a dtd/schema etc. Validation of other components of
build file may be possible but making the validator that general would
require a lot more work than I was willing to put in :P and it would just
end up creating a dynamic schema-dtd-like thing which I prefer not to go
through :P



| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |

View raw message