Right, this is what I typically do, so that I end up with an error object that contains not only type cast failures but validation rule failures as well. The only catch here is that for things that outright fail validation checks, the cloned object that repopulates the form doesn't have a value to redisplay to the user. Since typically cast failures are limited to things like dates or numbers, I check these using JavaScript or have the user make the choice from a select box or something like that. If you don't perform client-side checks, or the user disables JavaScript, it does mean that on rare occasions the redisplayed for will not be showing what the user entered for certain fields (i.e. if they enter letters for a date, that field is just empty when the form redisplays. The error message is there to explain the problem but the value they entered isn't.) Some people will say this is unacceptable for usability reasons but since the alternative is shadowing the properties with untyped functions, or manually building a separate object, I'm willing to accept this small issue. If it's really, really a problem you can disable type checking in the CF admin and let the validation catch the error instead. As far as I'm concerned, if the user disables JavaScript and enters "aaa" into a date field, it's just too bad that the redisplayed form doesn't show "aaa" in that date field. The validation error message tells them about the problem, and to me having "aaa" show up in the form again is just an invitation for the user to submit the bad data again.
On Wed, Oct 8, 2008 at 9:26 AM, Dan O'Keefe <[EMAIL PROTECTED]> wrote: > > Brian, > > Just to confirm, you clone a copy of the transfer object and then > attempt to set each of the properties with a <cftry><cfcatch> around > it so if any of the properties fails to set you note it, and if no > errors were detected you make a second pass at each property for the > additional rules? If any errors were detected on either pass you > return the cloned object to the form to re-populate the form. If no > errors were detected, save the cloned transfer object, if saved > successfully, update your original object from the clone? > > Sorry if that is a little incoherent, but I want to make sure I am > following you from form submission and back to the form if errors > occur, and if not, persisting to the DB. I have read the other posts > in the group here regarding changing the type to "Any" or not and I > think that is what you were addressing here. Also the issue of making > sure the session scope object in in sync as to what is in the DB. > > Thanks, > > Dan > > On Wed, Sep 24, 2008 at 12:22 PM, Brian Kotek <[EMAIL PROTECTED]> wrote: > > I have a Validator that first attempts to set the properties on the bean > (I > > use a Transfer object that has been cloned so that the updates don't > affect > > the real object until it is saved, but this could be done manually as > well). > > If any properties fail to be set (argument type failure), I record those > as > > validation errors and then move on. After the properties are set I run a > > validation on them to ensure that they conform to my rules (unique value, > > between two numbers, required, greater than/less than, etc.) and capture > > those as well. Only if the validator has no errors at this point do I > save > > the object. So you don't have to type your arguments to any, you can just > > capture setter failures and treat them like any other validation failure. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
