Object-oriented paging: anatomy of the "Pager" class - PHP

In order to set up the blueprints for the "Pager" class, let's start by defining the methods that compose it. As we saw in the previous article, the class will display two methods to work: the constructor itself and the "displayRecords()" method, which will take care of creating both the visual output for database records, and the corresponding paging links. Here's the first look at the class structure:

class Pager {

// properties declaration

function Pager(){

// parameters initialization

}

function displayRecords(){

// code to display records and paging links

}

}

As you can see, the skeleton of the class is very simple, and extremely understandable. So, let's examine the constructor to get a detailed understanding of its logic. At an initial stage, this method will accept only three incoming parameters: a reference to a MySQL's connection identifier, to provide database connectivity inside the class; an SQL query to get a result set (specifically a SELECT statement); and finally, the number of records per page to be displayed at a time.

Is that really all there is to it? Just three parameters and we're in business with the class constructor? Well, we'll add a couple of arguments later, but right now, the class structure might be redefined, including parameter initialization, like this:

class Pager {

var $conId; // connection identifier

var $query; // query performed

var $numRecs; // number of records per page

function Pager(&$conId,$query,$numRecs=10){

// validate connection Id

(mysql_query('SELECT 1',&$conId))?$this->conId=$conId:die('Invalid connection identifier.');

// validate query

(preg_match("/^SELECT/",$query))?$this->query=$query:die('Invalid query '.$query);

// validate number of records per page

(is_int($numRecs)&&$numRecs>0)?$this->numRecs=$numRecs:die('Invalid number of records '.$numRecs);

$this->output='';

}

function displayRecords(){

// code to display records and paging links

}

}

Now things are getting a bit more complex -- but not too complex, really. Let's take a look at what the constructor does. Since it accepts the three mentioned parameters, before assigning them as class properties, they should be properly validated.

In order to do that, first the methods check whether the connection identifier $conId corresponds to a valid MySQL connection, performing a simple "SELECT 1" statement against the selected database. If the query is successful, we have a valid MySQL connection identifier. Indeed, this little trick is useful to validate this kind of connection parameter. 

Please notice that we're using a reference to the connection identifier, not a copy; this is the reason for the usage of the (&) ampersand operator, preceding the parameter. 

The next task that the constructor performs is to validate the incoming SQL query, by checking whether it starts up with the string "SELECT". Since we don't need another statement, any query that doesn't fit this format is considered invalid, killing the script with a call to "die()".

The final parameter to be validated is the number of records per page, $numRecs, which must be a positive integer. In this case, I've opted to specify a default value of 10 records to be shown at a time. As usual, if it happens that this argument is not valid, the class is simply killed. 

By this point, the method has nicely validated the three parameters, assigning them as class properties. However, remember I said that we would add two more incoming parameters? Right, we need to provide the class a flexible mechanism to control the look and feel of database records, as well as of the paging links. Doing so, we'll make it more portable and extensible. How can it be done? We will simply implement a template file for records and a style ID for links. If this sounds confusing to you, just keep reading to learn more.