Neptune Information

Validation

Based on Dan Wilson's "So you want to build a ModelGlue:Unity application (Part 4)" (and the CFWheels version).

Now that we have list and form pages, we need to set up some simple validation.

Required

Let's start by making the "ContactType" field required. To do that, we need to mark it as required. We could do this directly on our form, but we can also make that change in the XML. Indicating them as required means that it will default to be required on any form that we create that uses this component.

<tables>
	<table entity="Contact">
		<field name="ContactType" Label="Type" type="text" Length="20" required="true" />
	</table>
</tables>

Make sure to add ?refresh=ContactOMatic in the URL to reload the ContactOMatic component (and any component that uses it).

The form should now show that field as required (the indicator for this is configurable).

This will also create both JavaScript and server-side validation. If you disable JavaScript and submit the form, you will see this as the result of server-side checking:

Regular Expressions

We could also use regular expressions for validation. For example, what if our client wanted to accept only contacts that started with "D":

<tables>
	<table entity="Contact">
		<field name="ContactName" Label="Contact" type="text" Length="120" required="true" regex="^D" />
		<field name="ContactType" Label="Type" type="text" Length="20" required="true" />
	</table>
</tables>

Note that since we are deviating from the standard set-up for the "ContactName" field we had to go ahead and include it in our XML.

Be careful to write regular expressions that will work in both JavaScript and ColdFusion as this will also be verified on both the client and the server. For now, however, we will keep the regular expression out of our code since we don't really need it.

Note that we could also use a type to indicate format (like "email" or "zipcode"). See cf_sebForm validations for more information.

Complex Validation

Sometimes, however, we need validation beyond what regular expressions can handle. For this example, we will insist that the "ContactType" is "friend" (this could actually be done with a regular expression, but to keep the examples simple we will pretend like it can't).

In this case, a little more work is required. First we must create an actual Contacts.cfc component that extends com.sebtools.Records (in the same folder that hold ContactOMatic.cfc) and add a "validateContact" method to it and then we must verify that the "ContactType" is friend.

<cfcomponent extends="com.sebtools.Records" output="no">

<cffunction name="validateContact" access="public" returntype="struct" output="no">
	
	<cfif StructKeyExists(arguments,"ContactType") AND arguments.ContactType NEQ "friend">
		<cfset throwError(Message="Contact Type must be 'friend'.")>
	</cfif>
	
	<cfreturn arguments>
</cffunction>

</cfcomponent>

This will return an error with a type of "ContactOMatic", which cf_sebForm is listening for as a validation error (this is set in CatchErrTypes - you can dump #SebForm# after the tag set to see the attribute values and more)

If the form is submitted with a different contact type then friend, the following validation error will display after the user submits the form:

Fun stuff! Now we have validation working. Let's go ahead and remove our regular expression and custom validation error (including the whole Contacts.cfc file, as it is no longer needed), though, to keep our program more clean and usable though (don't forget to refresh ContactOMatic).

OK. So our Contact-O-Matic has list and form pages with validation. It would be nice, however, if we could manage contact types...

Next: Multiple Tables

What is in Play?

Here are how the pieces fit together for this functionality.