On the general issue of the roles of converters and validators, it is certainly reasonable to think of the input (string->object) side of a converter as doing a validation -- in this particular case, a validation of a date format. Failure to conform to the required syntax and semantics of a date (such as 02/31/2005) should indeed cause a conversion exception to be thrown, because the input is not valid. In the same way, the characters "1a3" instead of "123" should throw a conversion exception when you try to convet that to an integer field.
Validators get to assume that the input value met the syntactic and semantic requirements for successful conversion. They focus on things like "is the specified date in the right range" etc. On the specific case of date conversions, check out SimpleDateFormat.setLenient(false) -- it will cause the formatter to reject 02/31/2005 as you might expect. Craig On Sun, 23 Jan 2005 12:20:38 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > I have some questions for the MyFaces folks about their thinking > concerning converters and validators. > > I'm reading a JSF book now that makes the argument that its perfectly > acceptable to perform validation in your converter. I think the > author makes a good case and I can envision scenarios where this is > actually necessary. > > I have one scenario in mind that has come up with our Struts project. > In Struts we have a converter that converts String to Date using the > SimpleDateFormat::parseDate method. That's fine except if the user > types in a date that doesn't make sense like '02/31/2005'. > Unfortunately Java just decides to convert it into a Date the best way > it can (without throwing an exception.) > > I was thinking that in this case, I would check for valid month, etc. > in my converter and throw a conversion exception if its invalid. > Otherwise its too late when you get to the validation phase because > the date is now valid (just not what the user entered!). > > Anyone have any thoughts on this (or the general strategy of where to > put validation logic?) > > TIA, > > sean >
