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

Class Action

We'll begin by tackling the "logic" in the middle first. I'll focus on particular scripts throughout the rest of this tutorial, to save column inches. The complete code is included for you in a ZIP at the end of the article. Note that the code here is based upon the code you'll find in the [eZ publish_root]/ezexample/ directory of your eZ publish installation. The eZ example module is a simple example of how constructing modules works, backed up by the tutorial: How to write database independent eZ publish modules. We're aiming to go a lot further than eZ example here, but for starting your own modules, eZ example is useful code to kick off with.

We've already created the database schema and eZ publish has an abstract database class with which to access it. The eZPublish framework will handle all matters, like connecting to the database and setting up the environment for us, so all we need to do is develop our classes "in a vacuum".

Specifically we're aiming to write code that will be capable delivering the data required to respond to the "events" we defined above. Also, we don't care about "presentation" issues right now (such as generating XHTML): all we're going to do is collect some data from the database, transform it, then deliver the results as PHP variables to anyone who happens to be passing through. This is an important point -- it's what the separation of logic from presentation is all about. As we're only going to deliver data with our logic classes, the "presentation" of that data is a separate problem. What we gain by doing this is the ability to present any user interface we like -- XHTML, WML, Flash, PDF, XML-RPC, SOAP -- you name it (PHP can do them all)! But don't let me distractou with all that right now-- just keep it in the back of your mind as you read on.

Looking at the events we've listed, it's pretty clear that the classes can be grouped around three different "things": categories, headings and FAQs. So let's decide we'll have three classes to deal with the user (site visitor) events, and three more to handle the administrator events.

But hold on a second! Some of what the administrators need to accomplish will be very similar to the users' events, such as being able to list and view FAQs. Aren't we going to be reproducing some of our code here? The answer is 'No', thanks to something called inheritance -- the ability of one object (a child) to inherit member functions from another (parent) object.

In PHP, this works using the extends keyword. The easiest way to see this is with an example.

<?php              
// The parent class              
class Senior {              
   function growUp ( $string ) {              
       return strtoupper($string);              
   }              
}              
             
// The child class extending the parent              
class Junior extends Senior {              
   function spellIt ($string) {              
       return strrev($string);              
   }              
}              
             
// Define a string              
$text = 'Hello World!';              
             
// Instantiate the child class to an object                
called "george" (just for fun)              
$george= new Junior;              
             
// Look - using the parent member function!              
$text = $george->growUp ( $text );              
             
// Now use the child member function              
$text= $george->spellIt ( $text );              
             
echo ( $text );              
?>

Results in...

!DLROW OLLEH

Hmmmm?!?

Using PHP's extends keyword, we can create child classes that inherit the "traits" of their parents: a very powerful technique for creating re-usable code.

So, going back to our eZFaq module, here's what we do: create three parent classes; eZFaq, eZFaqHeading and eZFaqCategory. Then we extend the parents with the child classes eZFaqAdmin, eZFaqHeadingAdmin and eZFaqCategoryAdmin respectively. Designing the classes this way, the advantage is not only re-usability. If we keep the parent classes to "secure" operations, such as fetching data, while the child "Admin" classes are the only place where "insecure" operations like UPDATEs and DELETEs can occur, we can ensure that our site visitors can never accidentally delete data through a mistake or hole we've left in our code.

I'm going to be concentrating on the eZFaq class and its child here, but you'll find all the classes in the ZIP at the end of this article. Down to business...