Ahhh, yeah, I can see how that wouldn't be worth the effort :-)
On Sep 26, 2008, at 10:10 AM, Brian Kotek wrote: > 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 cfcdev@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
