Jamie,
Thanks for describing it in these terms.
I'm going to take a shot at paraphrasing your levels with regard to a
database (since that is likely where the data will be stored):
1. Syntactic (data definition) is supported by field data type (and
"user defined" types like ssn or cc) and whether the field allows
null values.
2. Semantic (referential integrity) is supported by foreign key
constraints.
3. Paradigmatic (business rules) is supported by unique key constraints.
Paul
On 28-Feb-07, at 4:22 PM, Jaime Metcher wrote:
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]
Paul Marcotte
[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]
