I generally have two lists (or a struct, whatever), "RequiredFields" and "ErrorFields" and I pass
this to the view. When you are displaying each form field, do a check against this set. For example,
if the field name is in the RequiredFields list, display an asterisk, if its in the ErrorFields
list, use a different CSS class to color it red, etc. These both can be used together.
I send this data to the View from the Model (or Controller). Where you get this data (at least the
RequiredFields set) is up to you. You can store it in the DB, a flat file, or wherever. We use XML.
We describe our form in XML and then parse this on demand (optionally caching it) and can
auto-populate our RequiredFields list. The ErrorFields is set by your validation routine (one
approach is your validation generates a Query and then writes a set of messages to this. You can get
your field list by doing something like
<cfset ErrorFields = ValueList(ErrorSet.field_name)>
where this is captured in the first place like:
<cfset ErrorHandler("first_name", "You must provide your first name!")>
In this case ErrorHandleris a CFC which internally keeps track of the errors. This is super handy
because you can have all sorts of methods on it:
- hasErrors()
- getErrorCount()
- getErrors() (returns the query)
- getErrorFieldNames() (returns that list from above which you can just blindly
pass onto the View)
So during your action you can just add stuff to the ErrorHandler (keep it in Request scope or
something) and then at the end do something like:
<cfif ErrorHandler.hasErrors()>
<!--- go back to form --->
<cfelse>
<!--- do DB stuff --->
</cfif>
Since all your errors are encapsulated in one object, later you can modify it to log them to a file,
send an email, whatever, the client code doesnt care (or even know!)
As for the validation itself this belongs in the Model. Using our XML structure from above, I say
how to validate each field (this is a whole sub-system in itself). A sample element looks like:
<form name="user">
<field name="First Name" fieldname="first_name" required="true">
<dbmaxlength table="Users" column="first_name" />
<assert type="email" />
</field>
</form>
This is a super short example (and doesnt contain all of the attributes we use, like the actual
error string to display), but you get the idea. You can code this in such a way that all
"assertions" are a base class that have an "abstract" method process(). Each actual assertion,
"dbmaxlength" and "assert", implement this process() method. It can be a hefty little system, but
once you get it all worked out, its very powerful. We have implemented this system with great
success. We are thinking of releasing it as its own Form Validation framework.
One validation that gets called is checking the DB for column lengths. You can write a wrapper CFC
which communicates with the DB and verifies column lengths for you. Ours takes just a table name and
returns a struct of its data, most importantly return column widths. So you can do something like:
<cfset columnData = DBLengthUtil.getTableInfo("User")>
<cfif Len(form.first_name) GT columnData.first_name.length>
<cfset ErrorHandler("first_name", "First name field is too long! Max field size is
#columnData.first_name.length#")>
</cfif>
Of course, you will have to write the CFC yourself and return a struct that you can use (if you want
to be fancy you can return a object which has an API you can talk to). If you are using MSSQL or
MySQL 5, you can talk directly to "information_schema" and get all of the DB metadata you need.
For email do something like:
<cfif NOT ValidationUtil.isValidEmail(form.email)>
<cfset ErrorHandler("email_addr", "The supplied email is not in a valid
format")>
</cfif>
/Cody
Jason Daiger wrote:
This isn't CFC specific but I think this list is best suited to help
answer my question. I'm working on an application (built using Fusebox
5) and am using FB5 as the MVC framework. I am placing as much of
the business logic (i.e. Model) into CFC's as possible and keeping the
View's 'clean' from any business logic. I say clean b/c a view is never
"truly" business logic free. Simple example: email address is required
to create a profile in the system (business rule) therefore place a red
asterisk next to it on the data entry form. It's that form validation
area I'm looking for some suggestions/guidance. Where do people
place form specific validation, the Model or View? And by Form specific
validation I'm specifically referring to required fields, checking field
lengths, email address checks, etc.
Side note, I may have sat through one to many of Ray Camden's classes on
security and hence have become paranoid b/c I always check field
lengths, required fields, etc on the server side, regardless of what is
going on w/ the client side, just in case someone tried to save the HTML
page locally, hack it up and see what happens if they repost it. Also,
I understand that some other frameworks, such as Model Glue, encapsulate
all form or url parameters into a special object and pass this into
a CFC for processing and since FB5 does the same thing and places those
items in the attributes scope I could pass that to a CFC for
validation. However, that does not feel like a good idea and hence I'm
looking for suggestions & opinions.
Thanks,
Jason
Jason Daiger
PH: 410.480.8148 x301
EML: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
URL: www.attendeeinteractive.com <http://www.attendeeinteractive.com/>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of
the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
