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 13:47:44 GMT
At 01:50  30/6/00 +0200, you wrote:
>>>>>> "PD" == Peter Donald <> 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.

well as I said you can keep the same design contract but now it is handled
by AbstractTasklet rather than by the parser. The only difference is where
it is handled - and that handling it via AbstractTasklet allows other
design patterns when they are appropriate.

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

As I said there is 0 cost if you don't want/need it. If you don't want/need
it then you don't define the schema and no rules nothing is validated and
your task is processed exactly as it is now.

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

true the functionality can be placed somewhere outside the class but the
particular rules are associated  with the task (and therefore I think they
should be inside it). The way I do similar things in other like classes is
something like

protected SchemaRule[] getRules() { return null; }

public void execute( TaskContext context )
  m_context = context;
  final SchemaRule[] rules = getRules();  
  final Hashtable parameters = context.getParameters();

  if( null != rules ) validateParameters( parameters );
  processParameters( parameters );

whether the validation occurs inside or outside the class is not important
but what is important is that if you define a schema (via overiding
getRules) then it is automatically applied otherwise it is not.



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

View raw message