Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Listing 21.7 FormScr.htm (excerpt)—JavaScript Function to Validate Form Prior to Submission

//
//////////////////////////////////////////////////////////////////////
//
// This function will verify that the current form is ready to
// be submitted before allowing it to be submitted
//
function checkForm(formObj) {
//
// Verify that all fields have valid information in them
//
   for (i = 0;i < formObj.length;i++)
      if (formObj.elements[i].value == “” |
          formObj.elements[i].value == “Invalid”) {
         alert(“All fields must be completed with valid “
               “information for submission!”)
         formObj.elements[i].focus()
         return
      }
//
// Verify that the payment date is on or after the current date, and
// on or before the expiration date
//
   today   = new Date()
   today   = formatDate(today)
   today   = new Date(today)
   paydate = new Date(formObj.PayDate.value)
   expdate = new Date(formObj.ExpDate.value)
//
   if (paydate.getTime() < today.getTime()) {
      alert(“Payment date must be on or after current date!”)
      formObj.PayDate.focus()
      return
   }
   if (paydate.getTime() > expdate.getTime()) {
      alert(“Payment date must be on or before expiration date!”)
      formObj.PayDate.focus()
      return
   }
//
// Submit form
//
   formObj.submit()
   alert(“Form successfully submitted!”)
}

The checkForm() function does three things. First, it verifies that valid information has been entered into each field on the form. Rather than referring to each form field by name, it does this by using the elements object array of the form object, with the following for loop:

for (i = 0;i < formObj.length;i++)
      if (formObj.elements[i].value == “” |
          formObj.elements[i].value == “Invalid”) {
         alert(“All fields must be completed ” +
               “for submission!”)
         formObj.elements[i].focus()
         return
     }

If all the fields are not completed, an Alert box appears (see Figure 21.3), the form is not submitted, and the focus is moved to the first empty field.

FIGURE 21.3  Client-side processing is ideal for catching situations, such as this incomplete form, prior to submission.

Even if the form is completely filled out and each of the entries has the correct type of data in it, problems still might exist that you can catch at the client with JavaScript. checkForm() also checks for two types of invalid entries that can occur with either the payment or credit card expiration date. It is incorrect if either the payment date is after the expiration date of the card or the payment date is before the current date. In either of these cases, an appropriate Alert box appears, as shown in Figure 21.4, and the form is not submitted.

FIGURE 21.4  You can save effort on your Web server by using scripting to catch simple errors, such as an expired credit card, at the client.

After all the entries in the form have been verified, it is then ready to be submitted to the Web server for further verification of the payment information. You can also use JavaScript to put up an Alert box that tells you that your information is on its way (see Figure 21.5).

Verifying Well-Formed Credit Card Numbers

The only way to completely verify the validity of a credit card number is through a Web server specifically set up to handle credit card transactions. However, you can apply some checks at the client-side, using JavaScript, that enable you to determine whether the number is well formed. A well-formed number is one that could be a valid number for that type of credit card. Passing the test for being well formed does not mean that the number is from a good credit card; failing the test, however, does mean that the number can’t be from a good card.

You can apply two easy tests using JavaScript at the client-side. These tests enable you to determine whether a credit card number for a given card type is well formed. The first is to check the prefix (the first one to four numbers) and the length—each major credit card type has a given prefix and length. Second, most algorithms are encoded with a “check digit.” This digit is added to the number and can also be determined from the rest of the digits in the card by using a simple algorithm. Therefore at the client-side, you can apply the algorithm to generate the check digit and compare it to the digit actually present. If they do not match, the number is not well formed.

FIGURE 21.5  After all the entries are validated at the client as much as possible, they can be submitted to processing at the server.

Checking Card Prefix and Length

Table 21.1 outlines the major credit cards you might want to validate, along with their allowed prefixes and lengths. (Note that the JCB card type has two entries because it is either 16 digits beginning with a 3 or 15 digits beginning with 2131 or 1800.)