Conceptual Explanation

The first part of any shopping cart is the product offerings where customers can view their choices. Figure 14.1 shows an example of the product offerings for an Origami model store.

Once customers have viewed the product selection, they can choose the one they are interested in purchasing by clicking on the product name as seen in Figure 14.1. They now have the option to select how many frogs they want to purchase using the screen shown in Figure 14.2.

Figure 14.1: Initial screen for origami store.

Figure 14.2: Screen to specify quantity.

After entering in a quantity and clicking the Submit quantity button, the customers would be able to review their order, as shown in Figure 14.3.

Figure 14.3: Contents of the shopping cart.

The last part of the transaction typically involves the customer checking out and supplying the pertinent order and payment information, as shown in Figure 14.4.

Figure 14.4: Form to enter customer information.

This quick example obviously does not include all the necessary forms for a real transaction, but it does provide the basic idea of how a shopping cart functions on many online stores.

Shopping Cart Design

The design of the shopping cart begins with the design of the database. The initial requirement is to define tables for products, customers, and orders. Because the shopping process needs to allow for multiple products per order, a fourth table needs to be defined for ordered items. The entity-relationship diagram in Figure 14.5 shows the tables, the fields in the tables, and the relationship between the tables.

Figure 14.5: Entity-relationship diagram for orders application.

The shopping cart is only a subset of the many processes required for an e-commerce site. The processes described here include:

• Ordering products by viewing the items for sale and adding them to a virtual shopping cart

• Performing a checkout operation, including supplying name and payment information

• Adding new products to the database

Figure 14.6 shows the data flow for these processes.

Figure 14.6: Process diagram for the shopping cart.

Both an orders and an ordered items data store could be shown, but that is a greater level of detail than is needed for defining the processes. The main point to convey is that there are two processes being implemented, each involving a different agent. The application stores three types of information: product information in something usually called a catalog, information on orders, and information on customers. Therefore, adding a new product requires two operations: creating and uploading an image file for the product, and using the inputproducts script to add a new record to the catalog table in the database.

The storyboard for our PHP implementation is shown in Figure 14.7. The storyboard indicates that two scripts are contained in other scripts: the script establishing a connection to the database, and a script with a function for displaying the cart contents. This information is kept in a session variable. The heavy arrows represent linkages made by form action attributes. As indicated previously, dividing an application into several scripts is a good practice. However, you need to realize that the particular division is arbitrary. For example, the choice was made to make the submitorder script present a form, and be the handler for the form. You could decide to do things differently. Making the code that displays the cart functions a file by itself is a good practice, since otherwise you would need to repeat the code in each of the shoppingcart and submitorder files.

Figure 14.7: Storyboard for the shopping cart.

The storyboard for our ASP implementation would be similar, but not identical. The createtables script is not present. The fileupload script would be mentioned in the storyboard, but possibly with the php extension included because it is different from the others. To put it another way, the ASP implementation relies on two functions being carried out independent of the ASP scripts:

• The database and the database tables are created offline in Access and the entire database uploaded to the Web site.

• The image files are uploaded using a PHP script.

Session Information

The PHP and the ASP implementations each make use of sessions to hold the items ordered along with the quantity of each item ordered. The PHP session variable, named $cart, is an associative array. This is an array holding values stored by arbitrary keys as opposed to indices. To iterate through the cart, the code uses the foreach construction:

    foreach (@$cart as $pid => $qty) { 

which starts a loop in which each key/value pair is extracted from $cart. Within the body of the loop, the code references the key/value pair by $pid for the key and $qty for the value. You can use the foreach feature for any associative array, not just session variables.

The ASP coding needs to perform a similar job, although the terminology and the syntax are different. The data is stored in the Session.Contents collection. The term collection is what ASP calls an associative array. The expression Session.Contents.Count returns the number of key/value pairs. With this information, you can write the JavaScript for a loop:

    for (i=0; i<Session.Contents.Count; i++)

that can be used to iterate over all the key/value pairs in the collection. Within this loop, the statement:

    itemn = Session.Contents.key(i);

will assign a key (in this situation a product ID) to the variable itemn, and then:

    … Session(itemn)…..

can be used to refer to the corresponding value (in this situation, the associated quantity). The latter is shorthand for:

    … Session.Contents(itemn)…