DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15499>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15499 Validator does not successfully validate empty date fields. (#10349 revisited) ------- Additional Comments From [EMAIL PROTECTED] 2002-12-19 16:14 ------- The 12/19 nightly build does appear to work properly. In looking at the source for the 12/19 build, it appears to me that the problem in the beta 2 release may simply have been that in the beta 2 StrutsValidator.validateDate method an error was being added to the errors collection both in the case in which the date was not blank but invalid and when it was blank. That has been fixed in the FieldChecks.validateDate method in the FieldsChecks class where the code now resides. I agree that it seems a mistake to change the validator method from returning straight booleans to arbitrary types. Now the result is ambiguous: invalid? or blank? So, I have to test for blank in any case. Of course returning a boolean (and true when blank) changes the ambiquity to valid? or blank? I would prefer the latter. If the field is not required, I want the validity check to declare the input "invalid" when it is invalid, and I don't care that it is blank. That is, I don't want to have to execute a further test to determine whether it is blank. Returning only booleans also discourages using FieldsChecks as a data type converter. (In Struts, if I have to do data type conversions for persistence, say, I'm still going to have to call some conversion method again, so we don't gain anything in performance by returning the converted value in the FieldChecks methods.) As it now works, it appears that there is a mismatch between the results in Validator and what is being reported to the Struts Form in the errors collection when the date and other typed fields are blank. That feels a little odd to me. But given this disjunction doesn't appear to do harm, I think it best not to return a "dummy" value for these methods. Thanks for considering this issue. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
