From: "Steve Loughran" <[EMAIL PROTECTED]>
> I retrofitted <loadfile>, which only went in last week. The SrcFile trick
> makes coding easier, but it makes it hard for me to implement the "dont
> raise an excepto in failonerror=false", which is what I had originally
> implemented.
I am planning to revert to the old way of validations for now because
of opinions expressed that we discuss it further. But here is what I would
have suggested if we had planned to have SrcFile, etc. in place:
Task implements interface Failable which has two methods:
setFailOnError & getFailOnError. Introspector can then be modified
such that it doesn't throw an exception if getFailOnError returns false.
Side effect is it makes tasks have consistent 'failonerror' as
attribute name. I know Peter will scream at this ;-)
Another option is to pass File as argument to the setter method
and inside the set method or execute, call new SrcFile(file) and
then catch the Exception and handle accordingly. Ultimately,
the idea is to make sure that these validations are performed
uniformly in a (if possible) single place.
> So, if anyone had used the task we would have changed behavior.
Any problems if I roll back <loadfile> too to what it was earlier
when I do rollback on the others?
> -but they remove much of the flexibility of implementation
If flexibility is desired, then these new 'types' must not be used in such
a way that the Introspector uses it. You can instantiate it elsewhere
thereby gaining total control.
> The failonerror semantics is an issue; unless the introspection helper
calls
> getFailOnError() methods implemented in tasks it wont know the failonerror
> status, and even then we would need datatypes which differentiate
> "OptionalSourceFile" and
> "SourceFileWhoseAbsenceRaisesABuildExceptionOnlyIfFailOnErrorIsSet"
I believe I have addressed this with my earlier comments.
> I am +1 on metadata. Personally I think the md. associated with an attr
> should be very detailed:
>
> /**
> * @since 1.9
> * @ant:attribute set the dir to use
> * @ant:default current dir
> * @ant:optional
> * @ant:validator org.apache.ant.validators.SourceDirValidator
> */
> void setSrcDir( File src )
> {
> }
Are we planning to switch from a runtime interpreted environment to
a compile build file/execute build file scenario? Won't this severly
hamper the APIs from being used in a straightforward manner?
Can't we instead introduce methods like getSrcDirValidator,
getSrcDirAttribute, getSrcDirDefault, isSrcDirOptional, etc?
> void setSrcDir( File src ) {
> validator.validateSrcFileWithFailOnError(src,failonerror,"We cant use
> file {0} because of {1}");
> }
Problem is if somebody overrides this method in a subclass,
and implement their own stuff, validation will no longer occur.
Also, what if somebody overrides the method in the subclass
without providing them metadata details as proposed?
How will this be handled? WIll the superclass's stuff be
implemented or not?
Cheers,
Magesh
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
