Hi Brian, That is one solid approach. Another one (IMO no better or worse) is to type the arguments to any and to allow "invalid data" in the bean, running an isValid() on the bean to do all of the validations. There are two things I like about the typeless setters approach. One is that you can be much more granular in your error reporting, more easily. If you rely on a catch, all you really know is that the value entered wasn't a valid numeric or date. If you have a number of validations within the bean (probably composed in some kind of validator), you could be more granular in your checking and therefore in your error messages. I have come across cases where that was useful. I also personally use the bean to populate my form fields, so I can use the same code for populating the values for a first add form (using any defaults for a new bean instance), a second shot at an add (it shows exactly what you typed in - displayed in the fields again), or an edit (it shows the current values of the object). I find that works for me, but you do lose the documentation benefits of knowing what type all of your setter arguments are supposed to be. But I generate docs from my XML description of the object model (which also generates my db and synthesizes my code) and in most cases don't have the setter methods (or even the cfc's they're supposed to be in), so I gave up on making the code self documenting (as opposed to making the runtime system self documenting) a long time ago :-)
Best Wishes, Peter On Sep 24, 2008, at 12:22 PM, Brian Kotek 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. > > > On Wed, Sep 24, 2008 at 9:11 AM, Kevan Stannard > <[EMAIL PROTECTED]> wrote: > > Validation discussions frequently bring up the concept of populating > beans > with potentially invalid data then calling a bean.validate() > function, but > something doesn't quite feel right about it for me. > > If I have a date field in my bean, then I would like it to be a real > date > value (or an empty string meaning null), or if I have a numeric > field in my > bean then I want it to be a real numeric value. Allowing them to be > anything > entered by a user just doesn't feel right - but that is just where > my head > is at right now. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
