Writing Smart Web-based Forms
Forms are used frequently in dynamic web applications. As a consequence, almost all web programmers have to deal with form data validation at some point in their careers. The technique described in this article will help you help the user submit correct information.
So, what's the technique? Building smart forms... well, smart validation, actually. You are validating your forms on the server side, aren't you? You don't want to validate only on the client side.
I can't tell you how many web sites I've visited that don't handle input errors correctly. They either have forms that simply refresh with a generic "Your input has errors" message or they only report the first input error the validation script encounters (you'll have to turn off client-side scripting to view this gem).
An example on PowerASP.com has the beginnings of TheRightIdea™ and is worth a once-over. However, they miss the logical way of form validation and processing. The article details how to process forms and report one or more input errors using a form handler script and a redirect back to the form if there are input errors. Other than the fact that this method isn't the most logical way of doing things, there is also a loss of all of the users input unless they are also passed along in the querystring. Wasn't this supposed to be easy?
Writing smart forms can be easy if you want it to be. I'm going to use ASP in the actual examples, but the general concept can be applied using any language except ColdFusion; you just can't do ANYTHING good with that (direct flames to firstname.lastname@example.org).
There are a number of benefits gained by displaying and handling a form in the same file. First, we have all of the code related to that form in a single location (with the exception of code in include files). Second, we have available to our script every submitted form variable. The general flow of our form processing is as follows:
As you can see, we are validating the form before redirecting to any other page. In other words, the form is submitting to itself. Within this script, there is logic which determines whether it should display the form or process submitted form information. We are only moving from our script if the submitted form passes our validation. If the information does not pass validation, we re-display the form. We also pre-fill the form fields with the information already submitted and mark the fields that didn't pass our validation. This makes it easier for the user to supply the correct information.
So, let's say Joe User fills out the following form:
We don't like some of his input and our validation methods rejected it. Joe didn't even fill in his last name. He didn't even try with his email address. And that zip code is not the zip code for Evoltageddon, NH.
How do we present these issues to Joe User? Should we just tell him he screwed up and have him doing the work trying to figure out what is wrong (even though we've already figured out what's wrong)? No. We indicate to him that there is a problem with his submission with some generic text and highlight the fields that need to be corrected. The important part here is that both his correct and incorrect data is preseved so he doesn't have to re-type the correct information and he can also see what was wrong with his other information. So, we show Joe something like this:
You could take it a step further and display what was wrong with each field, but that is overkill for most situations. In this example, the only field that could warrant an explanation is the zip code field. However, the marked fields should do fine and there is only a very small chance that Joe will get confused.
What does this mean? Well, when you're building forms (and form handlers) you should:
- Make the form self-submitting
- Add logic to either show or process the form
- Validate submitted information on the server-side
- Redirect to the next page if information validates
- If the submission does not validate, re-display the form pre-filled with submitted info and problem fields highlighted
How can we determine whether to display or process the form?
Some people like to pick a form field and test it for a value. For instance:
if isEmpty(trim(request.form("firstname"))) then ' display the form else ' process the form end if
This method isn't the best way to do things. If I fill in every field but the first name field, the form is simply re-displayed, with no error notification (because the code doesn't know there's an error).
Another method is to pick the name of the submit button as the field to test:
if isEmpty(trim(request.form("submitButton"))) then Call displayForm() else Call processForm() end if
The above code simply checks if request.form("submitButton") has a value. If it doesn't, it calls
a subroutine called displayForm(). This subroutine simply writes the HTML for the form. If it
does have a value, it calls processForm(), a subroutine that validates the form input. You could
also skip the subroutines (but, it's so much cleaner looking, eh?) and slop all the code for each
condition within the
if test itself. However, when you scroll halfway down your script
and see an
else and you don't know what expression the corresponding
you'll understand why I did it this way ;-)
Still, I don't like this method much. If the value attribute of the submit button tag is omitted, isEmpty(trim(request.form("submitButton"))) will always be true. This is an easy thing to catch, but why bother when there are easier ways of doing things?
The method I prefer uses the server variable REQUEST_METHOD. Most likely, when Joe User first
visits your form page, his browser will use the GET method. When the form is submitted, the browser
will use the POST method (you are using
method="POST" when writing forms,
aren't you?). So, an easy way to check to see if the form has been submitted it to check the
if ucase(trim(request.ServerVariables("REQUEST_METHOD")))="GET" then Call displayForm() elseif ucase(trim(request.ServerVariables("REQUEST_METHOD")))="POST" then Call processForm() else ' are you supporting any other request methods? end if
What is an easy way to make a form self-submitting?
Simple. Another server variable available is SCRIPT_NAME. This holds the root-relative path as well as the filename of the current script.
<!-- expanded tag for readability --> <form method="POST" name="userdetails" action="<%Response.Write request.ServerVariables("SCRIPT_NAME")%>" >
How can I pre-fill fields with submitted data after an input error has been found?
Also fairly simple. Because the form is self-submitting, you have all the submitted form information at your disposal.
<input type="text" name="firstname" value="<%Response.Write request.form("firstname")%>"><br> <input type="text" name="lastname" value="<%Response.Write request.form("lastname")%>"><br>
Note that if you already have these form values stored in variables (which you should if you've already run the submitted values through validation), you should use those values rather than accessing them from the request object. More
It gets a little complicated if the form's purpose is to edit saved data in the database. The form will already have data in it before the user inputs anything. So, if they change something and there's an error with what they've changed, do you show the data from the database and let them re-edit that, or do you display what they've just entered? Truthfully, it's a mix. Here, we're going to give importance to the form data just submitted:
<% function getValue(byval sImportant, byval sPassive) ' notice that we aren't checking for ' a valid value, just *any* value if not isEmpty(sImportant) then getValue = sImportant else getValue = sPassive end if end function %> <!-- tags expanded for readability --> <input type="text" name="firstname" value="<%Response.Write getValue(request.form("firstname"),Recordset("firstname"))%>" ><br> <input type="text" name="lastname" value="<%Response.Write getValue(request.form("lastname"),Recordset("lastname"))%>" ><br>
getValue(...) above simply takes two values. The first value
is the value that should be returned if it has a value. If it does not have a value, we use
the second value. If the second value is simply an emptry string, then an empty string will be
returned. Since our first value is from the submitted form (if there is a submitted
form), then we are using the form input if it exists. Otherwise, we're using the data from the
So, how do I do this validation?
Well, it obviously depends on the information you're validating. However, in my experience, there are a few things that makes everything go a lot easier.
We need to know two things. First, we need to know if all the data validated. We also need to know which bits of data validated and which did not.
<% ' general true/false for ' validation of entire submission Dim bGoodPost ' specific true/false for ' validatin of each bit of data Dim bGoodFname, bGoodLname, bGoodEmail ' data vars Dim sFname, sLname, sEmail, sReferringFriend sFname = trim(request.form("firstname")) sLname = trim(request.form("lastname")) sEmail = trim(request.form("emailaddr")) sReferringFriend = trim(request.form("referrer")) if isEmpty(sFname) then bGoodFname=false else bGoodFname=true if isEmpty(sLname) then bGoodLname=false else bGoodLname=true if not isValidEmail(sEmail) then bGoodEmail=false else bGoodEmail=true bGoodPost = (bGoodFname and bGoodLname and bGoodEmail) if bGoodPost then ' validates!!! else ' re-display the form with values pre-filled ' and problem fields highlighted end if %>
Here we have four variables. The first,
bGoodPost stores whether
the entire form submission passes validation. This value is determined by the
required fields in the submitted form. In this example, firstname, lastname,
emailaddr are all required. referrer is not required and therefore we don't
care whether it has a value (though you may still want to validate
it if it does have a value, depending on the situation). So, we need to validate
these required fields.
bGoodEmail will hold whether each of these values are valid. For
sLname, all we do is check for a value.
sEmail, we run it through our own email-validating function
(not shown here, use your imagination ;-). Like I said in the beginning,
bGoodPost is true only if all of the required bits of information
pass our validation. An easy way to check for this is to use the line:
bGoodPost = (bGoodFname and bGoodLname and bGoodEmail)
bGoodPost will only be true if
bGoodEmail are all true. This is
exactly what we want.
Also note that
if bGoodPost then is the same as
if bGoodPost=true then.
After I've validated, how do I mark problem fields?
The easiest way to do this is to use the same subroutine you used to display
the form in the first place. In this example, it was called displayForm().
Now we have to add the highlighting functionality so that the user knows
which fields had errors. Ok, at this point (assuming the form has already
been submitted), we know whether the first name, last name, and email address
are valid. The variables
bGoodEmail tell us which values are valid and which are not. So,
depending on how you want to go, you can use one of the following methods to
highlight the fields with errors:
<!-- method 1 --> ... <tr> <td><font face="arial" <%if not bGoodFname then response.write " color=""#ff0000""%> >First Name</font> <input type="text" name="firstname" value="<%Response.Write request.form("firstname")%>" ></td> <!-- method 2, the cleaner method --> <td<%if not bGoodFname then response.write " class=""error""%>> First Name <input type="text" name="firstname" value="<%Response.Write request.form("firstname")%>" ></td>
Now, we run into a problem when the form is first viewed (before submission). All of those variables are going to be false. So, up where we're doing validation, we need to account for this case:
function isValidEmail(byval sEmail) ' very simple email validation function. returnVal = false if not isEmpty(sEmail) then if instr(sEmail, "@") > 0 and instr(sEmail, ".") > 0 then returnVal = true end if end if isValidEmail = returnVal end function if isEmpty(sFname) then bGoodFname=false else bGoodFname=true if isEmpty(sLname) then bGoodLname=false else bGoodLname=true if not isValidEmail(sEmail) then bGoodEmail=false else bGoodEmail=true bGoodPost = (bGoodFname and bGoodLname and bGoodEmail) if ucase(trim(request.ServerVariables("REQUEST_METHOD")))="GET" then bGoodFname=true bGoodLname=true bGoodEmail=true end if
And I'm sure you can think up some nice ways of getting around checking the REQUEST_METHOD twice in the same script ;-)
Sending a response.redirect (or equivalent in your language of choice) generates
a HTTP response code of 302 (the requested file has been found but it is in a
different location). Rather than it executing the redirection by requesting
the new location, in very old browsers an "Object Moved" page might be
displayed. This is obviously not something we want. In ASP, there is a method of
Server object called
Server.Transfer() is a server-side redirect, rather than a client-side
redirect. If this is available to you (ASP3/IIS5 and probably in other languages),
you will want to consider using that rather than sending a 302 header.