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 >after. :P~ > 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 Cheers, Pete *------------------------------------------------------* | "Nearly all men can stand adversity, but if you want | | to test a man's character, give him power." | | -Abraham Lincoln | *------------------------------------------------------*
