When working with forms, you often need to validate the data in the form-that is, you need to make sure that required fields are filled in and that the data in the fields is consistent with the requirements of the application.
For instance, if you have a form for inserting data into a table in a database, you wouldn’t want a user to providea string value for insertion into a numeric field because if you tried to insert the string value into the database, an error would be generated. The way to avoid this problem is to validate the data entered in a form prior to using the information.
Validating Form Data Using HTML Forms
The process of server-side validation is not complex:
1. The user fills in a form and submits it to a script or template on the server.
2. The script or template checks the data submitted. If all the data is valid, it is processed .
3. If the data is not valid, a new form asking for more information is presented to the user, who fills it in and submits it to the same script or template. Step 2 is then repeated.
Let’s walk through these steps one by one.
Ereating the Original Form
You can use any form tolearn form validation. Therefore, let’s work with something basic: a form asking for a person’s name, phone number, and e-mail address. To make things simple, you will enforce the following validation rules when you process the form data:
• The name and phone number are required fields. The e-mail address is optional.
• “The name should be no more than 50 characters in length.
• The phone number should be a seven-digit phone number in the form XXX-XXXX.
• If entered, the e-mail address should be of the form use firstname.lastname@example.org. The host. domai n portion of the address should, at a minimum, include a single dot.
• The e-mail address-should be no more than 30 characters in length. Creating the form itself is simple,
This code produces the form shown in Figure 16.1. Even before you get into serverside validation, you started the validation process in the form by using the MAXLENGTH attribute of the INPUT tag to ensure that the text entered in the fields doesn’t exceed the specified maximum lengths.
Validating the Data
Validation of the data is done in the submit. cfm template to which the data is submitted. At its most basic, the following steps need to occur:
1. Check all the fields to see if they are valid.
2. If any field is invalid, re-present the form.
Let’s try this, as shown in Listing 16,2
nus template may seem long, but it is really rather simple. The first step is to set two variables, Val; d and Er ro r, to default values. Val; d is a Boolean value indicating whetI1er the form contains valid data. By default, the assumption is made that the form is completely valid, and the variable is set to True. Error is a string variable that will hold any error messages that need to be displayed for the user. You are assuming that the form is.valid and that there are no errors to display, so initially the Error variable is the empty string.
Next you walk through a series of CFIF tags, which check all’possible cases in which data would be invalid. In all cases, if the data being checked is invalid,.va 1; d is set to Fa1se and an error message is concatenated to the Error variable by using the & operator. If more than one problem with the data exists, concatenating the errors results in all errors being displayed for the user. . Youneed to give some consideration to the last two CFIF tags and their conditions. Pirst.you check whether the phone number is valid with the following CFIF tag: <CFIF (Len(Form.Phone) is not and (not IsNumeric(Replace(Form.Phone,) or Len(Replace(Form.Phone,) is not 7» You start by making sure that the length of the phone number is not zero. nus is the first condition in the tag. If the phone number is not the empty string, then two more of the following conditions are tested to check for a valid phone number in the form XXX-XXXX:
1. You use the Replace function to replace the dash in the phone number with the empty string, effectively deleting the dash. Then you use IsNumeric to check whether the result is a numeric value. A phone number with its dash eliminated should be a numeric value.
2. Next, you again use the Replace function to remove the.sh in the phone number and then check that the length is seven digits long. All.Fone numbers in this example should have seven digits.
After completing these steps, you check whether the e-rnail address is valid. This is a little more complicated:
<CF5ET COt = 0>
<CFSET At2 = C>
<CFSET At = Firci (‘i” .Forrn.Email )
<CFIF At greater than 0>
<CFSET At2 = Find(‘,Form.Ernail,At+l»
<CFSET Dot = Find(.. Form.Ema’i l j At+L)
<CFIF (Len(Form.Email) is not 0) and (At is 0 or At2 greater than 0 or Dot is 0» To check the e-mail address, you first set some default variables to zero. You will use these variables in the process of building your decision, as you will see later. Dot reflects the presence of a,dot in the e-mail address whereas At2 indicates whether there is more than one at (@) symbol in the address, rendering it invalid, Next, you use Fi nd to search for the first occurrence of the @ symbol in the string and store the location in the At variable. Now you will check the value of the At variable. If it is greater than zero, then you may have a valid e-mail address. Therefore, you perform two more searches using the Fi nd function. You first search from the location after the previoks @ symbol for another and store the location, if found, in At2. Similarly, you search for a dot from the location after the first @ symbol and store the location, if found, in Dot.
The last step is to check whether the e-mail field is empty and if it isn’t, to check whether either At or Dot is zero or whether At2 is greater than zero. If any of these three conditions are True, then you have an invalid e-mail address. After you finish checking all the data for validity, you check the value of Val id. If it is False, you display the final error message stored in Error and then redisplay the form. Otherwise, you are free to process the data in any way you like. You won’t actually process, the code in this example because at this time you are concerned with the validation process and not what to do with the data once it is valid.
The end result of all of this is that if errors exist in the form, the user will be presented with the form shown in Figure 16.2.
A problem needs to be addressed with this template, though. The form presented to the user for reentering information is completely blank. However, presenting a form already filled in with the user’s original input is a good idea so that the user only has to alter the information already entered to make it valid instead of having to reenter all thedata . .This is done quite simply by using the form variables to set the VALUE attributes of the INPUTtags in the form, as shown in Listing 16.3
What you’ve done here is simpler than it looks at first glance. First, you use three variables to contain the HTML code to be displayed in the form for each field. You assume that the data is all valid, so the three variables (Name, Phone, and Email) contain hidden fields with default values set to the original information entered by the user. In addition to the hidden fields, you also display the original data.
The idea here is that if the use! enters valid. data, a hidden form field is used to include the data in any new form you have to display to correct otherinformation, However, you want the user to know what they have already entered, so you will display valid . values in plain text so the user cannot edit them.
Then, if you encounter invalid data as you are checking each field for validity, you can change the value of the variable corresponding to jhat field to an editable field containing the original data entered by tI;e user as the default value,
Finally, in the form itself, you simply display the value of the appropriate variable in each row of the table. If there is invalid data, the :esuIRng formhas fields only for the invalid data but still displays valid data for the user 1> reference. The result is like that shown in Figure 16.3. Here the name field is so is displayed as plain text rather than an editable form field.