The customer management process is provided by the customer/details.php , customer/validate.php , and customer/receipt.php scripts.
The script customer/details.php presents a form to both new customers and members who are updating their details. The form collects and inserts or updates data that is stored by customer/validate.php into the customer table. The customer table was created with the following statement:
CREATE TABLE customer ( cust_id int(5) NOT NULL, surname varchar(50), firstname varchar(50), initial char(1), title_id int(3), address varchar(50), city varchar(50), state varchar(20), zipcode varchar(10), country_id int(4), phone varchar(15), birth_date char(10), PRIMARY KEY (cust_id) ) type=MyISAM;
The form is initially empty if the user isn't logged in, and hasn't previously attempted and failed validation. If the user is logged in and validation hasn't previously failed, the form is pre-filled with her details from the customer table. Finally, regardless of whether a user is logged in or not, if data has failed validation, the invalid data is displayed for amendment. The customer form, showing errors from failed validation, is shown rendered in a Mozilla browser in Figure 17-1.
For new members, the form requires an email address that is used as the login name of the user and a password for future visits to the site. This information is stored in the users table that was created with the following statement:
CREATE TABLE users ( cust_id int(5) NOT NULL, user_name varchar(50) NOT NULL, password varchar(32) NOT NULL, PRIMARY KEY (user_name), KEY password (password), KEY cust_id (cust_id) ) type=MyISAM;
The table is identical to the users table discussed in Chapter 11, except we've added two extra indexes for fast searching by password and cust_id.
Two lookup tables are used for displaying and selecting the user's country and title. The customer table stores the identifiers title_id and country_id, and these identifiers are the primary keys of the titles and countries lookup tables, respectively. The contents of both lookup tables are displayed as drop-down lists using the HTML <select> element and make use of our winestoreFormTemplate select blocks. The tables were created with the following statements:
CREATE TABLE titles ( title_id int(2) NOT NULL, title char(10), PRIMARY KEY (title_id) ) type=MyISAM; CREATE TABLE countries ( country_id int(4) NOT NULL, country char(30) NOT NULL, PRIMARY KEY (country_id), KEY (country) ) type=MyISAM;
Passwords are digested so as not to be stored in plaintext anywhere; they're between 6 and 8 characters in length when entered by the user, but the digest process generates a string of 32 characters. For customers who are amending their details, the password and email input widgets are omitted from the customer form. If the user wants to change his password, he can use the change password feature discussed in Chapter 20. User names can't be changed; this is a feature you might add to a real-world application.
The customer/validate.php script validates the customer data that's passed through from the form using the POST method. If the customer is new and validation succeeds, the script inserts the new customer into the customer table, adds the new user to the users table, logs the user in, and redirects to the customer receipt script customer/receipt.php. If the customer is amending her details and validation succeeds, the script updates her row in the customer table and redirects to the receipt script.
On validation failure, customer/validate.php redirects to customer/details.php, where the validation errors are reported as batch errors that are interleaved with the form widgets. To display errors and the previously entered data, the script makes use of two session arrays that are populated by customer/validate.php as part of the validation process. This process is discussed in Chapter 10.
The customer/receipt.php script displays the customer details by querying the customer table and retrieving the details for the user who's currently logged in. Users can't view customer receipts if they're not logged in. An example receipt page is shown in Figure 17-2.
We reuse this template-based data entry process, validation, and receipt framework in other parts of the winestore. For example, the code is adapted for password changing and credit card data entry. The framework is explained in Chapter 16.