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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
