Sure that's fine if you have control over the typing. I use Transfer which types all of the arguments automatically, so unless I manually override every single getter and setter to retype them to "any", that won't work for me. And of course, I'm not manually overriding every getter and setter. ;-) I agree that if you're writing or generating your own beans, that typing to "any" is an option.
On Fri, Sep 26, 2008 at 8:09 AM, Peter Bell <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
