"Sounds like that second approach I mentioned is what you're doing, and I'm getting the feeling it's a good approach for most basic CF apps you'll come across. Factoring validation out into a separate object is kind of rubbing me the wrong way, though... it seems like you're breaking up the nice cohesion of a business object. Before, the business object was a nice encapsulation of business rules and data. But after factoring, you're left with a dumb data bean and a somewhat-stateless validation object that implements some of the procedural aspects of the business object. I guess I don't understand the advantage of splitting those apart."
Doug, Yeah, i came to exactly the same conclusion on the last coffee break. I realized that to be useful, the validator would need to preserve it's state so it could hold onto the "good" data, probably in session scope, and by the time you've done that, you've built the same object, just different in name. But i will keep Spike's approach in mind whenever the form and the business object would not mirror each other, and perhaps you have multiple forms for different aspects. Then it certainly does make sense to build a separate validator / transfer object. :) n. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
