Case Study: Adding Sessions to the Winestore - Page 9

The Validation Script

We begin the improvements to the validation script with the changes required to support an error message session variable and then discuss how to record the values to pass back to the client entry <form> generation code. We then present the complete structure of the modified validation script.

Improving error messages

We examine the changes required for error messages first. The validation script checks each variable submitted from the client <form>. Each field is checked with more or less rigor, depending on the purpose of the field. The script shown in Example 6-8 builds up a long formatted error message by concatenating error messages together as they are found. In the modified script, an associative array is registered to hold error messages associated with each field. This allows more flexibility when displaying the error messages.

First, we need to initialize a session and register a variable to hold an array of errors. This is achieved by adding the following lines to the start of the script:

// Initialize a session
session_start(  );
 
// Register an error array - just in case!
if (!session_is_registered("errors"))
   session_register("errors");
 
// Clear any errors that might have been 
// found previously
$errors = array(  );

Because this validation script may be called several times in a session, any errors that may have been recorded previously need to be cleared. This is the reason for setting the $errors value to a new, empty array.

The script checks each variable and adds an error message to the associative array $errors if an error is encountered. The error message is indexed by the name of the field being checked. For example, the validation of the surname is coded as:

// Validate the Surname
if (empty($formVars["surname"]))
   // the user's surname cannot be a null string
    $errors["surname"] = 
        "The surname field cannot be blank.";

Once all the fields have been validated, you can test the size of the array $errors to determine if any errors were encountered. If the size of the $errors array is 0, you create or update the row as before. If there are any error messages in the array, you need to display them.

// Now the script has finished the validation, 
// check if there were any errors
if (count($errors))
{
    // There are errors. Relocate back to the 
    // client form
    header("Location: example.8-5.php");
    exit;
}

In Example 6-8, the script itself displays any errors, and because the request contains variables in a POST method request, the resulting page suffers from the reload problem discussed in Chapter 6. In a nonsession-based environment, this problem can't be solved with a Location: header field, as the error messages are lost. In the validation script developed here, we relocate back to the client entry <form>--shown later, in Example 8-5--and let it display the errors held in the session variable $errors. We show the changes that allow the client entry <form> to display error messages in the next section.

Saving last-entered values as a session variable

We now develop the script to pass the field data from the validation script back to the client entry <form> to avoid rekeying when an error occurs. The script is modified by saving the user-entered data in another session variable, the associative array $formVars. The client details <form> already uses an array, $formVars, to populate the entry fields from a customer record when editing an existing client. By setting the $formVars session variable in the validation script, the client entry <form> populates the <input> fields with the values that were last entered.

The following code--inserted just after $errors is registered as a session variable--registers the array $formVars and then loops through each user-entered variable, setting a value in the array, indexed by the name of the variable. Note that the clean( ) function described in Chapter 5 is used to secure the user data.

// Set up a $formVars array with the POST variables
// and register with the session.
if (!session_is_registered("formVars"))
   session_register("formVars");
 
foreach($HTTP_POST_VARS as $varname => $value)
    $formVars[$varname] = trim(clean($value, 50));

When the modified client entry <form> is run, the most recent values entered from the session variable $formVars are shown.

WARNING:   While the $HTTP_POST_VARS associative array can be stored in a session and accessed like any other session variable, there is a catch. The value of $HTTP_POST_VARS is determined by PHP before scripts are run. If a session has registered a variable with the name $HTTP_POST_VARS, the values held in $HTTP_POST_VARS that were set up by PHP--as a result of processing a POST request--are overwritten by the session variable.

If register_globals is enabled in php.ini, the GET or POST variables PHP sets up can also be overwritten by session variables with the same name.

The safe way to read cookies, GET, and POST variables that have name conflicts is to use the $HTTP_COOKIE_VARS, $HTTP_GET_VARS, and $HTTP_POST_VARS associative arrays, as discussed in Chapter 6.

The final change needed in Example 6-8 is to destroy the session when the script successfully saved a row in the customer table:

// Clear the session 
session_destroy(  );

Case Study: Adding Sessions to the Winestore - Page 8
Web Database Applications with PHP & MySQL
Case Study: Adding Sessions to the Winestore - Page 10