Form Validation

The previous lesson covered how a form's fields arrive in the form scope, and introduced cfform's cfinput control. This lesson covers validating what actually arrives: cfinput's client-side checks, and, more importantly, isValid() and cfparam for validating it again on the server, since client-side validation only stops a well-behaved browser.

Learning Objectives

After completing this lesson, you'll be able to:

• Use cfinput's validation attributes for client-side checks.
• Validate a submitted value's real type or format server-side with isValid().
• Use cfparam to enforce a field's type and presence.
• Explain why server-side validation is required regardless of what the browser already checked.

Why Both Layers Exist

Client-Side: cfinput's Validation Attributes

A Real Example: Client-Side Validation on a Registration Form

<cfform action="process-registration.cfm" method="post">
    <cfinput type="text" name="phone" validate="telephone" message="Enter a valid phone number.">
    <cfinput type="text" name="email" required="yes" validate="email" message="Enter a valid email address.">
    <cfinput type="text" name="age" validate="range" range="18,120" message="Age must be between 18 and 120.">
    <cfinput type="submit" name="submitBtn" value="Register">
</cfform>

Server-Side: isValid()

isValid(type, value) checks whether a value actually matches a given type or format, returning a plain boolean rather than stopping execution, which makes it the right tool for building a real list of field-level errors.

<cfif structKeyExists(form, "submitted")>
    <cfif not isValid("email", form.email)>
        <cfset fieldErrors.email = "Please enter a valid email address.">
    </cfif>
    <cfif not isValid("range", form.age, 18, 120)>
        <cfset fieldErrors.age = "Age must be between 18 and 120.">
    </cfif>
</cfif>

Server-Side: cfparam for Enforced Type and Presence

<cfparam name="form.age" type="numeric">

A Real Example: Building a Structured fieldErrors Response

This combines this lesson with the throwing-exceptions lesson's structured extendedInfo pattern, checking each field with isValid(), collecting every failure into one struct instead of stopping at the first one.

fieldErrors = {};

if (!structKeyExists(form, "newsletter")) {
    form.newsletter = "false"; // unchecked checkbox never submits
}

if (!isValid("email", form.email)) {
    fieldErrors.email = "Please enter a valid email address.";
}
if (!isValid("range", form.age, 18, 120)) {
    fieldErrors.age = "Age must be between 18 and 120.";
}

if (structCount(fieldErrors) > 0) {
    throw(type = "Validation", message = "Registration validation failed.", extendedInfo = serializeJSON(fieldErrors));
}

Common Beginner Mistakes

Best Practices

• Validate server-side every time, regardless of what cfinput or HTML5 already checked in the browser.
• Use isValid() for checks that should collect into a field-level error list rather than hard-stop the request.
• Reserve cfparam for fields the request genuinely cannot proceed without, and pair it with cftry/cfcatch for a graceful failure message.
• Default a possibly-missing checkbox/radio field (from the previous lesson's gotcha) before validating it.

Interview Questions

Summary

In this lesson, you used cfinput's validation attributes for client-side checks, validated real submitted values server-side with isValid() and cfparam, built a structured field-level error response, and covered why server-side validation is required no matter what the browser already checked.

What's Next?

The next lesson covers URL parameters: reading the url scope, and safely defaulting or validating a value that arrived in the query string instead of a submitted form.