This is awesome stuff, Barney! It's what I've been needing to know for the longest time.
>>Client-side validation is a user-interface concern, because it makes the user interface "nicer", as it doesn't force a server trip for common validation issues. It should NEVER be relied upon for any part of you application. Given a choice, I don't even use client-side validation until the app is finished. It just gets in the way and potentially hides problems with the app itself. Agree completely. >>The two filters you mention populate a DTO and validate it. The DTO is then passed to your business layer and used to populate a BO, where it is validated again. In pseudo-code, how would you pass the DTO to the BO? If the data validates, why not pass the original data to the BO? >>The DTO validation (from ValidateFormObject) checks things like "date of birth (DOB) is a date in the past", or "Username isn't blank". Would the DTO validate _all_ data before throwing an error, or does it keep track using an Error Handler component and then, once all data has been "set"? I see this functionality such as: <cfset obj.setName = "Mike"> <cfset obj.setDOB = "tee-hee"> <cfset obj.phone = "123-456-7890"> <cfset obj.validate()> <cfoutput>#obj.isValidated()#</cfoutput> >>This is stuff that has nothing to do with the business rules of you application, but with whether the data reasonable or not. Syntactic, not semantic. Understood. >>The BO validation (from somewhere in your backend, long after everything Mach-II related has been left behind) is about the semantics for your particular application. the DOB field probably doesn't need any more checking, but the username might need to be checked for minimum and/or maximum length, and definitely whether it's unique or not. Why not check username length in the DTO? >>Your DTO should have every setter using 'string' as the argument type, because that's what every form variable is. Your BO, on the other hand, should have appropriate types. For example, the DOB field would be of type 'date'. This quickly demonstrates the need for two-stage validation, because the form field for DOB could happily contain "tee-hee", which would cause the setter on the BO to fail (because it's not a date). Are you saying that each DTO setter would allow a string argument, but then actually tests for the correct datatype? >>I'm not suggesting that you attempt this without need, but it's a great mental exercise that I use all the time. Does this have to do with user interaction, or does it have to do with the application's business functionality? NOTHING has to do with both. If you think something does, then you haven't broken it down into small enough pieces. "NOTHING has to do with both." Interesting mantra. I'll have to chew on this for a spell, but I'd appreciate any answers for the questions above. Thanks for the guidance! M!ke ---------------------------------------------------------- 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]
