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
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 StructureBefore 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:
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.
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.
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.
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:
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.phpLoad up the index.php file into your favorite text editor. It looks something like this (with terms of usage agreement stripped out):
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:
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:
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.
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:
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:
Now we want to delete the [Fruits] category, so what we should end up with is:
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.
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.
blog comments powered by Disqus