[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 To unsubscribe from this email please forward this email to [EMAIL PROTECTED] This email message is confidential and may be privileged. If you are not the intended recipient please forward the email to [EMAIL PROTECTED] and delete the original. ABN AMRO Morgans Limited and its associates hold or may hold securities in the companies/trusts mentioned herein. Any general advice included in this email has been prepared without taking into account your objectives, financial situation or needs. Before acting on the advice, you should consider its appropriateness or discuss with one of our investment advisors. ABN AMRO Morgans Limited (ABN 49 010 669 726 AFSL 235410) A Participant of ASX Group .A principal member of the Financial Planing Association . ---------------------------------------------------------- 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]
