From: "Peter Donald" <[EMAIL PROTECTED]> > the preprocessor will just generate the TaskInfo - not > any code as such. And if TaskInfo is absent then it > will be like it is now. If you want to implement > validators like you suggest then there is no support > required from the Container. You could simply add a > line into the execute method or wherever you wanted to > check the precondtions.
Exactly. The container can choose to provide some support - like invoking the isSrcDirOptional method, etc. The task writer can also choose to invoke the same methods, as you say. In other words, it gives flexibility to the task writer to manually do it as well as it gives the container hooks to perform automatic validations, etc. I still prefer having a datatype based validation approach because it plugs all holes - the task writer is ensured that validation *will* occur no matter how the setters are invoked... Why do we want to impose the restriction that the setters will work as designed *only* if they are invoked by the container? For example, a task's execute method might choose to invoke the setter methods repeatedly. Is the container going to capture this invocation as well? The downside is it may introduce a lot many more datatypes, but then, we can be smart about it and implement them as validator chains. > > > > Can't we instead introduce methods like getSrcDirValidator, > > > > getSrcDirAttribute, getSrcDirDefault, isSrcDirOptional, etc? > > > > > > Im not sure how that is easier. > > > > It is not just a question of easiness. I feel we need to > > factor in flexibility also. > > Flexability is easy enough to achieve. It basically > comes down to the language we use to describe the > preconditions/metadata. Basically, what do metadata provide that offer definite advantages over the methods based approach or the multiple datatypes approach that I suggest and also what limitations do they have? > > Pete > Magesh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
