On Tue, 2 Nov 2004 13:30:24 -0600, Dawson, Michael <[EMAIL PROTECTED]> wrote: > This is awesome stuff, Barney! It's what I've been needing to know for > the longest time. > > >>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?
You can certainly pass the original data to the BO, but it's a lot easier to pass one thing (the DTO) around your application rather than a bunch of individual form fields. I don't know about you, but I hate typing, and just the CFARGUMENT tags alone would be enough to drive my fingers mad. > > >>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> The EventBeanFilter does the equivalent of the first three lines, and the ValidateFormObject does the fourth. How you handle telling the user about any errors is up to you. > >>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? Because that's mixing your business logic in with your UI. Say usernames have to be 5 chars long. That's a business rule for your application, it has nothing to do with the user interface. What if that changes to 6 next year, and you're running a Mach-II interface, and a Flash interface? You don't want to have to go change your DTO from the Mach-II app, and also change the Flash movie to use the new requirement. Much easier to just change the single business component that both UIs share. > >>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? Yeah, basically. That's part of the syntactic validation. The right way to look at it is that form fields are always strings, that's and you don't want any validation errors when you're populating your DTO, so the arguments necessarily must be typed as strings. You want the validation errors to occur as part of the validate() method call, which happens separately, so that's where you have to check for the proper type (numeric, date, whatever). cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ I currently have 0 GMail invites for the taking ---------------------------------------------------------- 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]
