I tried it and it worked like a charm. In fact, I have incorporated it into a "validations framework" that I've been working on for the past several weeks. I will be discussing and documenting the framework on my blog over the next while, and hope to have a demo up any day now. So far I've just written an introductory post about the goals of the framework. If you're interested you can find that post here:
http://www.silverwareconsulting.com/index.cfm/2008/10/6/ValidateThis--An-Object-Oriented-Approach-to-Validations Bob On Thu, Oct 9, 2008 at 2:59 PM, Dan O'Keefe <[EMAIL PROTECTED]> wrote: > > Bob, > > Was wondering if you gave this idea a spin and have prototyped it - > and if so, did it work as expected for you. > > Thanks, > > Dan > > > On Thu, Oct 2, 2008 at 9:31 AM, Bob Silverberg <[EMAIL PROTECTED]> wrote: >> >> I spent some time discussing this with Paul Marcotte last week and we >> came up with an idea that I think is similar to what Brian was >> suggesting. Here's what we came up with: >> >> Keep business object exactly as it is, with typed getters and setters. >> Include the "shadow property" logic to store invalid data that cannot >> be stored by a setter. As the business object is created by a >> business object factory, wrap the business object in a generic >> wrapper. That wrapper would use onMM to pass all setters to the >> underlying business object, and to allow all getters to first check >> for a shadow property and if one does not exist, then pass the getter >> to the underlying business object. >> >> This would allow one to keep the API of the business object, without >> having to resort to generic getters and setters, but would remove the >> previous requirement (in my implementation) of having to write a >> custom getter for any properties that need to be able to store invalid >> data. You could then use your business object directly in your view >> and would always get back the data that the user submitted, valid or >> not. >> >> I haven't actually written this yet (I will), but in theory it sounds >> pretty good. >> >> Comments? >> >> On Fri, Sep 26, 2008 at 5:08 PM, Bob Silverberg >> <[EMAIL PROTECTED]> wrote: >>> I have yet to come up with a solution to that problem that I'm really >>> happy with. Currently my populate method, which loads data into the >>> business object and validates the datatypes, takes any invalid values >>> and stores them in "shadow" properties, from which I can retrieve them >>> when I need to display them. Unfortunately this technique requires a >>> custom getter for any properties that could have invalid values (most >>> are strings, so they don't need this functionality). Another way >>> around this is to use a generic getter that checks for the existence >>> of an invalid shadow property, and calls the standard getter if no >>> invalid value has been stored. But I'm not too keen on that either. >>> >>> So, my solution works, allows me to use my business object directly in >>> my view (e.g., myObj.getName()), and also allows me to redisplay any >>> invalid values entered by a user, but I'm just not that keen on the >>> implementation. I hope to one day either hear of a better >>> implementation or come up with something on my own. >>> >>> >>> On Fri, Sep 26, 2008 at 4:51 PM, Kevan Stannard <[EMAIL PROTECTED]> wrote: >>>> Hi Brian, Mark >>>> >>>> >>>> >>>> If a form field contains invalid data that cannot be set on a bean due to a >>>> type failure, how would you handle redisplaying that original invalid data >>>> back on the form again? >>>> >>>> >>>> >>>> Thanks >>>> >>>> >>>> >>>> Kevan >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of >>>> Brian Kotek >>>> Sent: Thursday, 25 September 2008 2:23 AM >>>> To: [email protected] >>>> Subject: [CFCDEV] Re: Using object "getters" after form validation fails >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >> >>>> >>> >>> >>> >>> -- >>> Bob Silverberg >>> www.silverwareconsulting.com >>> >> >> >> >> -- >> Bob Silverberg >> www.silverwareconsulting.com >> >> > >> > > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
