ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: [RFC] AbstractTasklet with extended functionality
Date Fri, 30 Jun 2000 11:50:14 GMT
>>>>> "PD" == Peter Donald <donaldp@mad.scientist.com> writes:

 PD> At 10:08 30/6/00 +0200, you wrote:

 >> I'm very much fond of the way attributes and nested elements are
 >> reflected into tasks. It would probably also break scripting
 >> support.

 PD> you want to keep it ? Easy keep it.

No, I want it as the contract of Task - and that I can't keep if we
switch to your proposed TaskContext. Correct me if I'm wrong.

All attributes that can be set from outside the task (or a nested
element that gets the same treatment from ProjectHelper BTW) are
detected by a specific Ant design pattern - which happens to be the
same as for beans.

The same is true for nested sub elements of tasks (or of sub elements
again), you can identify them because there is an Ant internal design
pattern - method without arguments that returns an object type and
whose name starts with "create".

 PD> It is just that most of my tasks are scattered with things like

 PD> if( null == m_someProperty ) { 
 PD>     throw new BuildException("Property 'someProperty' not set");
 PD> }

So a task that wants this validation would initialize AbstractTasklet
with a list of acceptable properties, a list of required properties, a
list of properties that are not allowed to be combined, a list ...

This might become even more cumbersome if a task inherits from a
subclass of AbstractTasklet.

I see this - the reoccuring parameter validation blocks - as a problem
as well, but don't feel that reusing some kind of abstract rule
validator by inheriting from it is the right way. If you can come up
with an easy to configure validator, it'd be better used by the task
than inherited from IMHO.

Stefan

Mime
View raw message