Hey Alan, > Is this not what the bean setter methods are for. ie calling setSomething() you can make it richer by > checking for invalid values and setting a default there. Then this logic isn't needed at the validate() > or save() stage?
When I wrote that I was thinking of a particular situation that I ran into a few months ago where the default value couldn't be deduced so readily. There were multiple ways to save a certain object. In one usecase, the object was being created straight up and strict validation for all properties was required. In a second usecase, the object was an insignificant piece in a much larger process and it would have been inappropriate to stop the flow on its account. So if the user failed to provide valid data, we intelligently deduced appropriate values given other data involved in the process, and the user would later be able to correct the value had we deduced wrong. Long story short, for this particlar case I couldn't hard-code into the setter, but that is not to say that I don't do what you described all the time when appropriate. > Also, when needing different validate methods depending on what needs to be validated I had > some success with the State / Strategy pattern. The factory can set the bean up with the correct > concrete validation strategy object (ie my RegistrationValidationStrategy calls validate() in the > abstract ValidationStrategy first then runs its own validate() method). Its more complex and > probably overkill for most situations but at least the factory handles it so it keeps things cleaner. I'm a huge fan of the state / strategy pattern and use it all the time for situations like this where slight variations are required. It works well with the result object concept we have been discussing because the majority of the logic remains in the object, but you can still call both validate() and save() together in the service, return the multiple required objects, add a tweak or two that wouldn't really make sense in the object, and be flex ready. Baz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
