Sean, converters are a big plus to JSF, so it's posible to use clazzes like Date or even your *custom* clazzes
To ensure that all get right converted, it is ok to validate the value. example: you have an inputText for email address if it should go to String property of your backing bean, no *converter* is needed, just validate the string If it goes to an object of EmailAddress clazz, than you need a converter. So here is also some validation needed. But Converter is not only for input, it helps you *presenting* the value of your custom objects instead of presenting e.g. [EMAIL PROTECTED] I hope I got your points... -Matthias > -----Original Message----- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 23, 2005 6:21 PM > To: MyFaces Discussion > Subject: Converter vs. Validator > > > 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 >
