Rob Wilkerson

I've been meaning to write about the approach I take to submitting forms for a long time now, but reading Jeff's post the other day (it's taken me a while to write this up) on doughughes.net got me thinking about it again and inspired me to write (even though this isn't specifically related to validation). After reading the methodology I employ, I'd like to hear what others do.

Everywhere I've been, approaches have differed widely and in many cases espoused vociferously. I won't detail the varying approaches I've seen and heard of - they're not revolutionary in any way. I don't consider my approach new or revolutionary in any way, either. I do the same things in a slightly different way, but since I've never heard or read about anyone else doing the same thing I thought I'd take the time to put it out there. Hopefully I'll learn something from any responses.

An Overview

First, my method assumes self-submitting forms. I can't remember the last time I submitted a form to a different action page (not that there's anything wrong with that). Given this precondition, I usually have three primary blocks of code on a form page:

1. Environment Definition: This is my way of referring to request level code that is required for both of the following blocks. This block usually includes variable assignments and defaults and any common queries (which is a variable assignment, I suppose).
2. Form Handler
3. Form Display

In my code, these blocks are identified as minimally as I can think to break them down:

The environment code is straightforward enough. My approach seems to be unique (in my experience, of course) in the blocking method in the way I handle the form and in the error display.

The Form Handler

I've always hated the approach to form submissions that applied arbitrary variables defined "form stages". You know, like the "view" stage or the "process" stage and maybe even the "validation" stage. To me, this just seems overly verbose and I'm a laconic kind of guy. Handling a form, in my mind, includes validation and is not necessarily independent of the form display. If an error occurs then I want a message to display above the form. It's a usability thing.

Handling a form, somewhat obviously, breaks down into two primary stages: validation and processing. As part of my minimalist preference, another thing I want to avoid is a lot of conditionals. I've seen a lot of handlers that perform some validation and then have a conditional that states "if everything is okay so far, then continue". I never got that. That's why the try/catch block exists. Using try/catch, I can quickly and efficiently distinguish between and handle catastrophic processing errors that must be addressed immediately and errors that can be collected and displayed en masse to the user like field validation.

A typical form handler block, for me, might look like this (excuse the interwoven pseudo-code. I'm not working off of a "real" example):

The Form Display

Nothing much to see here.  Just the normal form stuff with a little bit of error handling.  I have a UDF (or a method, depending on which approach makes the most sense for the project) that accepts an error array and spits back an XHTML string to display the messages in a lovely unordered list.

The UDF/method itself looks something like this:

Put it all together and whaddya got (hint: it's not bibbity bobbity boo)?  A clean, workable form flow.  At least in my opinion.  Everything reads - and functions - top to bottom with no oversized blocks of conditional logic.

So that's how I do it.  Anyone else have a different methodology you care to share?