eZ publish: PHP's Killer App - Parts 1-3

The Drawing Board

Before you reach for that text editor and start hacking, let's make a plan.

Our fantasy Website, phpPoint, regularly receives mail from people asking questions about PHP. To prevent site administrators from answering the same question twice, you decide it's time to put up a list of commonly asked PHP FAQs. The big question is: how to display them?

Now you could take advantage of eZ article and publish a either the entire FAQ as a single article or new article for every FAQ. Either way, you're not convinced. Better would be a categorised list of questions and answers that visitors can browse and search. So it's time to build the eZFaq module...

The FAQs will come in two main groups: categories, which are broad "overall" groupings, and headings which are "sub groups" of category. The FAQs themselves will appear under these headings.

When viewing the contents of a category, all headings under that category should appear, along with all FAQs associated with each heading, so that a simple view of the page might look like:

Meanwhile, the phpPoint administrators need to be able to create, edit and delete FAQs. You decide they will first see a list of categories. Clicking on a category gives a list of headings then clicking on each heading, the FAQs within that heading will be available. The end result should be something along the lines of a Web directory like dmoz.org.

We have a rough idea of where we're going now, and if you look closely at the above description, you'll notice it describes a data relationship, and makes the suggestion that users should be able to search FAQs. How would this look as a database schema? Using the eZ publish table and column naming conventions it might be:

#              
# Table structure for table `ezfaq_faq`              
#              
             
CREATE TABLE ezfaq_faq (              
 ID int(11) NOT NULL auto_increment,              
 Question varchar(255) default NULL,              
 Answer text,              
 Published enum('1','0') NOT NULL default '0',              
 Date int(11) NOT NULL default '0',              
 HeadingID int(11) NOT NULL default '0',              
 PRIMARY KEY  (ID),              
 FULLTEXT KEY Question (Question,Answer)              
) TYPE=MyISAM COMMENT='Many to one on ezfaq_heading';

Note: eZ systems have opted to store date information in MySQL as simple integers (UNIX time stamps will be stored in them, in fact) rather than using the MySQL 'DATETIME' column type -- in general, a good idea for database abstraction.

Another note: if you're querying the FULLTEXT index on Question and Answer -- you'll see this in action later, but it's worth having a look at the MySQL manual on Full Text Searches as well as Building a full text search engine with PHP.

#              
# Table structure for table `ezfaq_heading`              
#              
             
CREATE TABLE ezfaq_heading (              
 ID int(11) NOT NULL auto_increment,              
 Heading varchar(255) default NULL,              
 Published enum('1','0') NOT NULL default '0',              
 CategoryID int(11) NOT NULL default '0',              
 PRIMARY KEY  (ID)              
) TYPE=MyISAM COMMENT='One to many on ezfaq_faq              
- many to one on ezfaq_category';              
             
#              
# Table structure for table `ezfaq_category`              
#              
             
CREATE TABLE ezfaq_category (              
 ID int(11) NOT NULL auto_increment,              
 Category varchar(255) default NULL,              
 Published enum('1','0') NOT NULL default '0',              
 PRIMARY KEY  (ID)              
) TYPE=MyISAM COMMENT='One to many on ezfaq_heading';

Notice the relationships between the tables (see the comment with each table for a description)? We'll need these when we access the tables. Also, we'll use the "Published" column that appears in each table as a switch -- this way, rows can be made visible to phpPoint administrators so they can edit them without being visible to our site's visitors until they're ready.

So far, so good. The next question is: what "events" should the FAQ module be able to perform? And not just for users, but also for site administrators...

• Users (site visitors)
• List categories from the ezfaq_category table
• List headings from ezfaq_heading table, grouped under categories
• List FAQs from the ezfaq_faq table, grouped under headings.
• Search for FAQs
• View a single FAQ
• phpPoint Administrators
• List/ Create / Edit / Delete categories
• List/ Create / Edit / Delete headings under categories
• View / List/ Create / Edit / Delete FAQs under headings

So what have we got here? We've effectively outlined multiple "tiers" of an application. We began be looking at how the application should be presented to its users. Then we created a database schema that the application will access. Finally we defined a list of events we can use to build the logic of our application.

In general, thinking about applications this way -- regarding each as a series of layers -- allows us to treat each one as a separate problem and go about solving it without needing to worry about what's happening elsewhere. If I can interrupt your reading for a moment, you might find this an interesting read.

As an application, eZ publish structures itself, more or less, into "presentation" (XHTML), logic (the classes and code that make it hum), and data (the database and abstract classes used to access the data). By following the above design strategy, we'll find it fits nicely with building the module itself.