Honestly, I don't know the answers to your questions. I validate my form fields and pass them to my business logic as a bunch of individual fields, rather than using a DTO. At the most, I might use a structure, particular for multi-part forms. The separation of syntactic and semantic validation is still there, I'm just doing the syntactic validation in a procedural way, rather than an OO way.
I personally think that the controller layer of an HTML application should be procedural in nature, simply because that matches up with the HTTP paradigm. I dislike Mach-II for exactly this reason, greatly prefering Fusebox. If you're doing a RIA or something, then different rules apply of course. It's worth stating that I could remove my Fusebox controller and replace it with a Mach-II controller with a fairly small amount of fuss. The two frameworks are much alike, and the app-specific code within the framework is broken down in similar ways. The manner for wiring it together into a cohesive whole is very different of course, but if the pieces are properly abstracted and encapsulated, the wiring is a trivial task. That diverged nicely, didn't it. Oh well. When Barney's tired and grumpy he gets ranty and long-winded. cheers, barneyb On Wed, 17 Nov 2004 11:05:41 +1000, Scott Barnes <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote on 17/11/2004 10:34:12 AM: > > > Also, DTOs shouldn't have any logic in them. If you want to use a DTO > > for validation, the validation routine should be external and you pass > > the DTO in to it. Again, it's not really changing anything, it's just > > (sorry focusing on this one part, the rest I'm comfortable with saying i > understand). > > Ah, that's where I was "eh?" on the entire process. I thought from one of > your earlier posts, that a DTO had some UI specific validation in it as > well (i.e. is an email address formatted correctly - 'if @ not defined > blah'). I ask this as a FORM scope is basically string values > (regardless), so does the DTO assume all of its properties are also string > values or do you put type checking in place? (i.e. cfargument tag will > throw an exception if say i pass in a date to an argument type of numeric? > - which in a way means it has logic while its very raw & basic, its still > logic - so should i treat all type="string" or put type casting in place > via this tag?). > > I only ask this, is if the DTO is to assume all is string, maybe the "UI > validation object" carries out type checks and making sure things are > formatted correctly (universal dates etc) then returns a cleaned DTO for > server-side layer use. > > eg. of a procedural approach to a DTO concept above: > > 1. User Submits a form to a page. > 2. CFM then grabs the form scope, feeds the form fields into a DTO and > hands that object to a "UIBean". > > 3. The formBean then validates against basic UI rules (i.e. date is a > date, integer is an integer, email has an @ in there somewhere etc). At > this point i could return a newly revised DTO or wait for a request for it > (ie getBlahDTO() ). > > 4. That revised DTO then gets feed into a Bean for serverside validation > (unique db details etc? or whatever non-ui specific rulings that need > execution). > > 5. And from here you can either go into CRUD (via DAO) or do whatever you > want, knowing full well your DTO at this point has been processed and > cleaned and ready for storage. > > Typically I've worked in the fashion of having UI Validation & Server > Validation in the one BO as the applications are simple enough for this? > then handing that BO (because its server side now and trust is inplace) > but having read previous posts it appears that others prefer to separate > the two? > > Once again, thanks for your help on this quandary. > > > > Regards > Scott Barnes -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ ---------------------------------------------------------- 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 [EMAIL PROTECTED]
