Structure and Page Progression

As we are wont to do, before sitting down to write the SimpleBlog system, we spent some time planning out the pages we would write and the way in which we will divide the various tiers of the application. As shown in Figure 32-3, our application is a series of pages that interact with various middle-tier services, most notably the user manager, entry manager, and comment manager.

Figure 32-3. The various services and components of the SimpleBlog system.

Page Layout

The SimpleBlog web application consists of eight primary visual pages and an error page to display critical errors in our application that are often not the result of user input. Figure 32-4 shows the complete possible progression of pages; we can see that those pages that are forms (for creating accounts, or entering comments and entries) also have associated pages to process the input for them. (See the section titled "Processing Forms and Page Progression" in Chapter 31, "An Appointment Manager.")

Figure 32-4. Page progressions in the SimpleBlog web application.

The key pages in this web application are as follows:

index.php This is the starting page for this web application. It lists all of the users in our system. Each of these is presented as a hyperlink that can be clicked to view the journal for the specified user.

createnewacct.php Users visit this page to create a new account in our blogging system. Usernames created on this page must be unique, and it is an error to visit here if there is a user logged in for the current session.

showentries.php This page displays all the blog entries for a particular user. The user can either be specified via the uid parameter, which holds the user ID of the user whose entries we are to display, or if that is not specified, by the g_loggedInUID variable, which holds the user ID of the user logged in to the current session. If a uid parameter is not specified and there is no logged in user, an error is generated.

showentry.php This page shows the details of an individual entry, including all the contents associated with it. The entry to show must be specified by providing the eid parameter with a valid entry ID.

newentry.php This is how users write a journal entry in their blog. It presents a simple form. The user must be logged in to write an entry, and if he attempts to write one without being logged in, he is redirected to the login.php script, which sends him back here on successful login.

newcomment.php Replying to an entry or a comment associated with a particular entry is done through this page. The exact entry being replied to must be specified by the eid parameter, which contains a valid entry ID. The user must be logged in to view this page; if he is not, the user is directed to the login.php script and redirected back to this page after successfully logging in.

login.php To create new blog entries in their own journal or to reply to an entry in anybody's journal, users must log in to the blog system. Users can log in via the menu bar across the left of all the pages, or are sent to this page when they attempt to visit a page that requires a login. In this latter case, a target parameter is sent to the login.php script, which is either ent, in which case the user is sent back to newentry.php after logging in, or com_XYZ, in which case the user is sent to newcomment.php with the eid parameter being set to XYZ. It is an error to visit this page if the user is already logged in.

logout.php To log out of the blogging system, users can visit this page, in which case the system removes all the details of their login. It is an error to visit this page if the user is not logged in.

As mentioned earlier, each of the pages based on form input (createnewacct.php, newentry.php, newcomment.php, and login.php) has an associated script to process the user data before sending the user to some other page. These four pages are submitnewacct.php, submitnewentry.php, submitnewcomment.php, and submitlogin.php respectively. None of these latter pages has a UI, and on failure either sends users back to the original form to correct their input or sends them to error.php, which displays more serious errors.

Database Structure and Notes

The database setup for this sample reflects the more ambitious scope of the web application. In addition to having a table for the entries that users write, we create a table for the users themselves and a table for the comments that people associate with entries. Finally, because we have a complete system for managing logged in users, we also have a table to keep track of them.

We make much greater use of foreign keys in this sample, so we will create all the relevant tables with the InnoDB table storage engine in MySQL. (See the section titled "Table Storage Engines" in Chapter 9, "Designing and Creating Your Database.") We create the database and accounts to work with it via the following queries and statements (MySQL syntax shown):

 CREATE DATABASE SimpleBlog   DEFAULT CHARACTER SET utf8   DEFAULT COLLATE utf8_general_ci; GRANT CREATE, DROP, SELECT, UPDATE, INSERT, DELETE   ON SimpleBlog.*   TO 'blog_admin'@'localhost'   IDENTIFIED BY 'blog_admin'; GRANT SELECT, UPDATE, INSERT, DELETE   ON SimpleBlog.*   TO 'blog_user'@'localhost'   IDENTIFIED BY 'blog_user'; USE SimpleBlog; SET NAMES 'utf8'; 

The Users table in the database is straightforward and just stores the key information for a user. Usernames must be unique, and they must specify a password, e-mail address, and full name. Birth dates and user descriptions are optional, and for birth dates, we will let the user specify only portions of itsuch as December 1900, or February 12. We will search frequently on the user's name, so we will create an index for that field:

 CREATE TABLE Users (   user_id INTEGER AUTO_INCREMENT PRIMARY KEY,   username VARCHAR(50) UNIQUE NOT NULL,   password VARCHAR(50) NOT NULL,   fullname VARCHAR(200) NOT NULL,   email VARCHAR(200) NOT NULL,   birthdate DATE,   userbio TEXT,   INDEX (username) ) ENGINE = InnoDB; 

Journal entries are not at all complicated. They have a title and a body (at least one of which must be specified), a posting date/time (which is managed by the system), and an author ID, which is determined and set by the application:

 CREATE TABLE JournalEntries (   entry_id INTEGER AUTO_INCREMENT PRIMARY KEY,   title VARCHAR(200),   posted DATETIME NOT NULL,   author_id INTEGER NOT NULL,   body TEXT,   FOREIGN KEY (author_id) REFERENCES Users (user_id) ) ENGINE = InnoDB; 

Comments are stored in a format very similar to entries in the database, except that they are associated with a particular entry, and thus have an enTRy_id field to point to this:

 CREATE TABLE JournalComments (   comment_id INTEGER AUTO_INCREMENT PRIMARY KEY,   entry_id INTEGER NOT NULL,   author_id INTEGER NOT NULL,   posted DATETIME NOT NULL,   title VARCHAR(200),   body TEXT,   FOREIGN KEY (entry_id) REFERENCES JournalEntries (entry_id),   FOREIGN KEY (author_id) REFERENCES Users (user_id) ) ENGINE = InnoDB; 

Finally, to help manage logins, we create a table that connects user IDs to session IDs. This table has to be cleaned up periodically, because the user might close the web browser without clicking the Logout link, but this rarely turns out to be a problem for us. We also store a last access time in this table, which we update whenever a user accesses a page in our system. Logins that have gone more than two hours (configurable) without any activity are considered "stale" and deleted. We search frequently on the session ID, so we will create an index for that field:

 CREATE TABLE LoggedInUsers (   user_id INTEGER NOT NULL,   session_id VARCHAR(255) NOT NULL,   last_access DATETIME,   FOREIGN KEY (user_id) REFERENCES Users (user_id),   INDEX (session_id) ) ENGINE = InnoDB; 

UI Strategy

In the Appointments web application, we demonstrated using file inclusion as a means of generating a user interface in our various pages. In the SimpleBlog system, on the other hand, we demonstrate a UI-generation class we have written called HhtmlGenerator. By calling a few key methods on this class, we generate most of the key interface elements in our web application. The general pattern of any pages in our application that generate a user interface will be similar to the following:

 <?php ob_start(); require_once('simpleblog/'); /**  * Start generating the page.  */ $hg = HtmlGenerator::getInstance(); $hg->startPage('SimpleBlog Login Page'); $hg->openBody(); $hg->emitLeftMenuBar(); $hg->openContent(); // generate page-specific HTML here. /**  * Close out the page and exit.  */ $hg->closeContent(); $hg->closeBody(); $hg->closePage(); ob_end_flush(); ?> 

For the XHTML that we generate for each page, we use a combination of simply displaying markup elements for individual pages and creating new routines on the HtmlGenerator class to help share common UI features across pages.

All of our pages use Cascading Style Sheets (CSS) to further customize the final interface generated by our application. This is stored in basestyle.css and is included in all pages by the startPage method on HtmlGenerator. We use style sheets mostly to set color and font properties on various markup elements in our output.

Complete File Listing

Table 32-1 lists all the files in our SimpleBlog web application.

Table 32-1. A Complete Listing of Files in the SimpleBlog Sample





User page

Lets the visitor create a new journal account.



Cascading Style Sheet used in all of the visual pages in the application.


User page

Used to show complex errors to the user (not simple input errors).


User page

The start/home page for the application. Lists all the users currently in the system and permits them to view their blogs.


User page

The user logs in to the system via this page.


User page

Logged in users can log out of the system via this page.


User page

This is the form via which a user enters a comment for a blog entry.


User page

Users write new journal entries with this form.


User page

Lists all of the entries for a particular user.


User page

Shows an entry and all of its associated comments.


Processing script

Processes the data from the login form and performs the login or sends the user back to the login page.


Processing script

Validates the data from the create account page, and either creates the account or sends the user back to the account creation page.


Processing script

Takes the data for a new comment and submits it to the middle tier for insertion into the database.


Processing script

Executed after a user submits a new entry. This script makes sure that the data is valid and submits the entry to the middle tier.


Contains the classes for creating and managing comments associated with entries.

Organizational helper

This file is included in all of our scripts so that we do not have to worry about which files to include.

Database helper

Contains the information needed to connect to the database.


Contains a class used to connect to the database.


Contains the classes for creating and managing journal entries in our application.

Organizational helper

Contains a set of functions and exception classes to help with error handling.


Contains a class we use for the generation of the user interface in the sample.

Organizational helper

This file is included via It determines whether there is a user logged in before we execute a script.

Organizational helper

Sets up all the code for our session that we need, including some security features.


Contains the classes to manage users in our system, and to log them in and out of the system.

Core Web Application Development With PHP And MYSQL
Core Web Application Development with PHP and MySQL
ISBN: 0131867164
EAN: 2147483647
Year: 2005
Pages: 255

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: