All the techniques presented here are quite intelligent and elegant but I want to throw out an idea. Whether someone uses a helper component, shadow properties or a validator, at the root there is always a need for some sort of USER api to store and manage the data. Is that not the purpose of having a USER class to begin with? To have a definition of an api from which many different instances for all types of purposes can be created? It *feels* like if 99% of an interface needs to be duplicated, then the class definition is too tightly coupled to a specific implementation and that one would be better off dumbing down the original class in favor of more composition/inheritance for the added functionality. To go back to the original example, Michael instantiated one instance of the USER class to store the logged-in user's information. Later on, he may instantiate more user objects to display query results or show someone's manager. They all share a common api but serve very different purposes with their own set of unique rules and constraints to follow. So why not just have another instance that is specifically designed to handle dirty data for validation?
The way I would solve the problem most closely resembles Peter's technique. I would have a LOGINUSER stored in session (for things like displaying their name at the top of the site) - and if someone wanted to edit that USER, I would create a new instance specifically for that unique purpose. That new instance might interact with my session instance (to populate itself perhaps), but it is still a separate special instance whose surrounding code is specifically designed to handle and expect potentially dirty data. So the form that is being used for editing, would only interact with that instance. It would display its contents, edit its contents and so forth, with no fear of that spreading to other parts of the site. Only once the entire editing process is complete would I update the SESSION.LOGINUSER instance with the new data. That's why I am not a huge fan of shadow properties even though they do provide a lot of elegance in certain cases - there's too much duplication. It *almost* makes more sense to compose a USER object within itself - one clean and one dirty. Caveat: I understand this wouldn't work out as nicely with transfer for reasons mentioned before. What do you think? Baz On Thu, Oct 9, 2008 at 5:56 PM, Bob Silverberg <[EMAIL PROTECTED]>wrote: > > 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: cfcdev@googlegroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of > >>>> Brian Kotek > >>>> Sent: Thursday, 25 September 2008 2:23 AM > >>>> To: cfcdev@googlegroups.com > >>>> 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 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 -~----------~----~----~----~------~----~------~--~---
