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