ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: building myrmidon
Date Sun, 13 Jan 2002 06:24:54 GMT

> From: Magesh Umasankar []
> > this would be better done in a type 
> > descriptor (say).  But then you (the task writer) have to use 
> > one way (method name) to specify max multiplicity and a 
> > completely different way (type descriptor) to specify min 
> > multiplicity.  Should we care about this?  Maybe we stick 
> > with setter and adder until type descriptors become a reality 
> > (though that very cool Xdoclet stuff makes it look like not being 
> > too far away).
> As I had pointed out earlier, meta data usage to mark a
> setter as optional or required may not be the best way to
> do it because sometimes, one attribute may be mandatory
> depending upon another attribute not being set, etc.  In other
> words, task writer may have to write code to check
> if an attribute is mandatory or not.

Both forms of validation are useful in different cases.

Meta-data is declarative, so we can use it to do things like generate docs or validate early
in the build process.  However, it suffers from a lack of flexibility.

Programmatic is infinitely more flexible, but really can only be applied just before the task
is executed (if you want to keep that flexibility).

If I had to choose one of them, I'd pick meta-info, cause anything that saves me writing boiler-plate
doco is an excellent thing, and I can always put whatever complex validation I need in my
execute() method (doesn't help me with data types, however).

However, we don't necessarily need to pick one or the other - they are complementary, and
could be mixed and matched as the task writer saw fit.

> So, what I had suggested earlier was this:
> After having called all the set methods, the container
> would call isXOptional() methods before invoking
> execute().  Thoughts?

Maybe a meta-info interface might be better?

Either way, the issue of validation is very closely related to the configuration/meta-info
issues discussed (among other places) on the "IntrospectionHelper Request" thread.  If we
get the meta-info story sorted out, then validation will just fall out (with any luck).


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message