Building an E-Commerce Site Part 1: Building a Product Catalog - Step 4: Creating Catalog Maintenance Screens (
Page 7 of 8 )
Now that you have a good understanding of how the products and categories are
going to work, we will create some maintenance screens to allow administrative
users to manage them. Download the mymarket1.tar.gz
file and extract it into your web root directory. For example, if your web root
is in
/home/httpd/html
type
$ cd /home/httpd/html
$ tar -zxf /tmp/Commerce1_mymarket1.tar.gz
Assuming that you've downloaded mymarket1.tar.gz into /tmp. Now, open up the
file application.php and change the $CFG->wwwroot and
$CFG->dirroot paths to match your server configuration.
Directory Structure
Before we dive into the source code, let me
explain how I've setup the directories and files. Once you go into the
mymarket directory, you will see four directories and one file:
drwxrwsr-x 3 ying ying 1024 Apr 20 01:38 admin/
drwxrwsr-x 2 ying ying 1024 Apr 20 01:38 images/
drwxrwsr-x 2 ying ying 1024 Apr 20 01:38 lib/
drwxrwsr-x 2 ying ying 1024 Apr 20 01:38 templates/
-rw-rw-r-- 1 ying ying 1732 Apr 20 01:39 application.php
The
admin directory is where we will be working in for
the rest of this howto. It holds all the administrative scripts for us to manage
the data.
The images directory is where we would store pictures if we had any.
You can fill it up with neat graphics and icons when you start playing with the
site.
The lib directory is where our library files will go. These are
standard functions that we will use throughout the site, so it makes sense for
us to store them in one location.
The templates directory will hold template files for the site. When
building dynamic web pages, my personal preference is to separate the processing
code from the display code. In our case here, the processing code consists of
all the PHP commands we write to perform the actions. The display code consists
mainly of HTML code, as well as some PHP commands to aid in the creation of the
HTML code. More on this as we work through the code.
The application.php file is where our configuration and settings
reside. We will include this at the top of all our scripts so we can have a
common script to define all our settings. This is similiar to the
Application.cfm files in ColdFusion, except ours isn't loaded up automatically.
If that makes no sense to you then don't worry about it.
Before we go too far, let's take a look to see what standard libraries are
available. In every PHP application that I write, I always have a set of
functions that I reuse over and over. These are just some handy functions that
make my life easier when I write more complicated code.
lib/dblib.php
This is a database abstraction library that I use when writing code. One
thing about PHP that I find lacking is the consistency of their database
functions, or the lack thereof. Every database that you use has a different set
of function names. I wrote a simple library that wraps the MySQL functions that
I call, so that if I ever need to switch over to a different database I only
have one place to change all the database calls.
NOTE: In practice, it's not all that fun adapting your code to different
databases. It takes good planning to make your application easily portable to
different databases. Having a database abstraction library is nice, but then you
have a bigger problem in that things you take for granted in one database are
not available in another.
lib/stdlib.php
This is a subset of my standard library of functions, it contains mainly
string functions that help when I'm displaying output or when I'm dealing with
variables. Take a look through the comments in this file to familiarize yourself
with functions. Now on with the show.
admin/
Now let's move into the admin directory, since that's where all the
action.
If you take a directory listing of the admin directory, you will see
this:
drwxrwsr-x 2 ying ying 1024 Apr 20 01:38 templates/
-rw-rw-r-- 1 ying ying 5069 Apr 20 01:38 categories.php
-rw-rw-r-- 1 ying ying 1727 Apr 20 01:38 index.php
-rw-rw-r-- 1 ying ying 6881 Apr 20 01:38 products.php
You will notice that there is a
templates directory
here as well, it will hold template files that are specific to the
administrative area.
The categories.php script is the one that will handle all of our
category management functions. It contains all the processing code and logic to
add, edit, delete, and list categories. There is no display code in this script,
it uses templates from the templates directory for displaying output.
The products.php script is the one that will handle all of our product
management functions. As with the categories.php script, it contains all the
processing code and logic to add, edit, delete, and list products. There is no
display code in this script, it uses template from the templates directory for
displaying output.
The index.php script is just a simple "Welcome to the Administrative
Area" screen. Now let's go through these scripts to give you an idea of what is
going on.
admin/index.php
Load up the index.php file into your favorite text
editor. It looks something like this (with terms of usage agreement stripped
out):
<?
/* index.php (c) 2000 Ying Zhang (ying@zippydesign.com)
*/
/******************************************************************************
* MAIN
*****************************************************************************/
include("../application.php");
$DOC_TITLE = "MyMarket Administrator";
include("templates/header.php");
?>
<p class=normal>
Welcome to the MyMarket Administrative menu!
<pre>
TERMS OF USAGE:
</pre>
<?
include("templates/footer.php");
?>
Aside from the displaying a Terms of Usage statements (which
I've cut out here) the script really just boils down to a few commands:
include("../application.php");
This includes the application.php file and sets up the program settings, and
more importantly, it creates the configuration object $CFG. We've already been
introduced to the $CFG->wwwroot and $CFG->dirroot properties, you can take
a look at the application.php file to see what others there are.
$DOC_TITLE = "MyMarket Administrator";
Sets up the name of this page into the $DOC_TITLE, and the command:
include("templates/header.php");
displays a standard Administrative header page that prints out the name of
the document and some standard administrative links. The rest of the file is
pretty self-explanatory, but you should be able to see that with the bulk of the
display code (HTML) going into separate template files, the file is much cleaner
to read. You can easily see where your logic is and what you are trying to do
without sifting out the HTML. This file was actually a bad example since there
is no logic in here, so on to the categories.php file.
admin/categories.php
The categories.php file is a bit more interesting because it handles all the
category management functions. If you pull up the file, you will (hopefully)
appreciate the cleanliness and simplicity of the code. With all the display code
moved to a template file, all you are left with it the core logic that drives
this script:
switch (nvl($mode)) {
case "add" :
print_add_category_form(nvl($id, 0));
break;
case "edit" :
print_edit_category_form($id);
break;
case "del" :
delete_category($id);
print_category_list();
break;
case "insert" :
insert_subcategory($id, $HTTP_POST_VARS);
print_category_list();
break;
case "update" :
update_category($id, $HTTP_POST_VARS);
print_category_list();
break;
default :
print_category_list();
break;
}
There's all the logic that drives all the category management
functions, isn't that nice and compact? Where are the functions? The are down
below, because in PHP 4 you can call functions before you define them, this
further allows us to keep our code neat and tidy because we can put the main
logic up front and show our function declarations later.
I won't go into the specifics of the functions, because you should be able to
follow the code and comments to figure out what is going on. Instead I will
cover the general steps involved in each of the functions.
Adding a Category
To add a category into the database, we just have to issue a simple INSERT
statement with the ID of the parent category, the name we want to give the new
category, and a description. We have to ask the user this information, so we
present them with a form (mode=add) and then run the INSERT statement after the
form has been submitted (mode=insert).
Editing a Category
To edit a category, we must first pull the existing information from the
database. Once we've done this, we can pre-fill the category form with the
existing information (mode=edit) and then update the database after the form has
been submitted (mode=update).
Deleting a Category
Deleting a category is a bit more complicated an operation, the reason is
that we have to do something with its subcategories and its products. The
solution will be to reassign all the subcategories and products under this
category to this its parent. For example, let's say we have:
[Top]
|
+--[Fruits]
|
+--[Apples]
+-- Kiwi
+-- Banana
Now we want to delete the [Fruits] category, so what we should end up with
is:
[Top]
|
+--[Apples]
+-- Kiwi
+-- Banana
Everything that was under the [Fruits] category was shifted up one category,
so they are under the [Top] category now. To do this in the database we must
delete the category in question, then reassign the products and then the
sub-categories.
Listing the Categories
This is a simple SELECT on the database, and then printing out the
information into an HTML format. On the listings, we will want to provide links
for people to add, edit, and delete categories, as well as adding products into
categories.
admin/products.php
The products page is very similar in layout and functionality to the
categories page. They both offer the same features, just that they operate on
different tables. One thing of interest to product maintenance is the
one-to-many relation between categories and products. Since one product can
belong to many categories, our product entry screens have to allow us to select
multiple categories.
Adding and Editing Products
To assist in this, I've written a function to create a multi-select listbox
that attempts to print out the category tree. With the categories that we've
entered so far, the listbox looks like this:
Sub-categories are automatically indented (notice Apples and Berries), and
the categories to which this product belongs are automatically selected. To
build this, I recursively make queries to the database to print each category
level. This isn't efficient, but it is easy to write and understand. You should
try to come up with a better algorithm, especially if you are going to have a
lot of products.
The queries to INSERT and UPDATE products more complicated than with
categories because of the one-to-many relation. When we perform INSERT and
UPDATES, we have to make sure the relation ship table products_categories
has the correct records to link this product with the appropriate
categories.
When we are creating a new product, we have to INSERT one entry into the
products_categories table for each category this product belongs to. On UPDATEs,
we must first delete all records in the products_categories table for this
product and then rebuild them as we do with INSERTs.
/ 102 
