>>>>> "PD" == Peter Donald <[EMAIL PROTECTED]> 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 after. 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. Stefan
