IMHO there are really three levels of validation that correspond in language terms to syntactic, semantic and paridigmatic correctness.
1. Syntactic - is the data OK at a field or bean level? If you're running username/password authentication, a bean that represents a user's login attempt but has no password is just plain invalid all by itself. Or you're asking for a credit card number and someone types in an alphabetic character. Often you'd do this validation in the client (and again on the server side, of course). 2. Semantic - does this set of data say something meaningful? In a registration form, both the password and password (again) fields are OK individually, but they aren't the same as each other. Or you've got an address with a US state but the country is set to UK. 3. Paradigmatic - the data may be correct individually, and may be meaningful as a set, but you might want to disallow it anyway. Somebody is trying to register but they already have a user account. The credit card details are good but the account is over its limit. Where you put the concepts in your domain will be highly specific to your application. Your syntax might be someone else's paradigm. Now, if you think of a little hierarchy of processing like this: service bean controller client-side you can map the possibilities for the three levels of validation. In a nutshell, you can push all three levels up to the top of the processing hierarchy (service), but you can't push them all down to the bottom. So some people advocate doing just that (pushing everthing into the service) - because it's simpler, because the less the lower layers have to do the less they have to know, which makes initialization easier, etc - others are more eloquent on this. But it requires more discipline to keep the service code nice and cohesive. Whereas others like to spread validation across these layers, because if all the little bits of your system are a little bit smart, there's less pressure on the master layer to know everything. OTOH, the prospect of all your little bits of smart getting out of sync and disagreeing with each other gives some people the willies. Jaime Metcher -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter J. Farrell Sent: Thursday, 1 March 2007 8:48 AM To: [email protected] Subject: Re: [CFCDEV] Where should I validate form submissions? Nando said the following on 2/28/2007 4:32 PM: > Why shouldn't a user know how to validate it's own data? To me it depends on how much you need to validate your bean. We have some pretty complex validation routines in one our applications. We needed access to UDFs, which felt dirty to inject in the bean (I know that Peter Bell would disagree), manage UDFs inside the bean or use cfinclude (could cause namespace issues). We also sometimes have to do more complex things -- like checking if the password meets our requirements -- all the normal stuff plus things like not allowing stupid words like first/last name, email address or current user name. All of this requires access to things external to the bean -- this of course is overly simplified for illustration purposes in this email. So after a while, letting the bean know how to validate itself became unreasonable for us. In the end, we don't mind that our beans are very stupid and a bit anemic. Those are my two cents and I'm sure in the future I'll have more to say. > Maybe you could try both approaches and see which you like better? Most definitely. Trying is the only way you learn otherwise we can debate this forever! ;-) .Peter -- Peter J. Farrell - Maestro Publishing http://blog.maestropublishing.com -- Co-Host of the ColdFusion Weekly Podcast http://www.coldfusionweekly.com You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected] You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
