Surely, one of the most common applications we've seen in modern sites is a paging system. Although its use has been with us from long time ago, paging systems are a must for websites needing to expose massive amounts of data. However, here we’re not going to stop for a long while explaining the motives of why you should implement such a system. By now, our immediate goal is to show its structure and demonstrate how it can be integrated with a database abstraction class.

Through previous articles, I’ve thoroughly covered the interesting topic of displaying paginated data in websites using PHP, developing either a procedural solution or an object-oriented method. Just in case you’re not aware of, visit here to have a full review of the different solutions implemented to addressing the problem.

However, when we hopefully solved this issue by creating a “Pager” class, it originally exposed two noticeable features, worthy to consider: first, it accepted as an incoming parameter, a reference to a MySQL connection identifier, for providing database connectivity within the class structure. Second, the class was conceived to work independently, presenting its own methods to perform SQL queries and obtain result sets.

Now, we’ll refactor a bit the class code (just in case that you don’t know, Refactoring is the process to restructure code without changing its functionality), in order to make this class “aggregate” our already known “MySQLConnector” class. Sounds rather confusing? Well, let’s take a look at the skeleton of the newly defined “Pager” class, to clarify any possible inconvenience:

class Pager {
    var $db; // MySQLConnector object
    var $query; // SQL query
    var $numRecs; // number of records per page
    var $output=''; // dynamic output
    function Pager(){
        // code for parameter initialization
    }
    function displayRecords($page){
        // code for displaying records and paging links
}

If you look at the above code, probably you’re saying…Hey, I’ve seen this stuff before! Sure, you’re all right. I’ve shown this class in my previous articles dedicated to implement a paging system. But, let’s not judge the tool without first spotting the differences. Please remember that we’re refactoring the class code, so the class is still pointing its guns to display paginated data.

But, here’s where things get a lot more exciting. Notice that the class presents a $db data member. So, what’s that thing? Well, this data member directly represents a reference of a “MySQLConnector” object, that will be passed straight to the constructor, for being used to obtain paged result sets.

In other words, our “Pager” class aggregates the “MySQLConnector” object’s capacities for its own purposes. This is Aggregation in a nutshell! Isn’t it sweet and simple?

I'm okay, just got caught in the moment. But, let’s completely write the constructor method, so we can see how it incorporates the “MySQLConnector” object. Its definition looks like this:

function Pager(&$db,$query,$numRecs=5){
    $this->db=&$db;
    (preg_match("/^SELECT/",$query))?$this->query=$query:die('Invalid query '.$query);
    (is_int($numRecs)&&$numRecs>0)?$this->numRecs=$numRecs:die('Invalid number of records');
}

As you can see, the constructor takes three parameters. The first, as you might easily guess, is a reference to an instance of the “MySQLConnector” object (notice the & ampersand operator preceding the variable name). Still with me right? Fine, the second parameters is a “SELECT” SQL statement, which will be performed against the selected database. Finally, the third parameter determines the number of records per page to be displayed in the web page. As usual, for this argument, I’ve opted to specify a default value of five records.

The code inside the method is hopefully easy to pick up. In the first place, it assigns the “MySQLConnector” object as a class data member, using the line:

$this->db=&$db;

Now, this object is available inside the class to be mercilessly exploited! Don’t you feel like this class is the bad boy of the block? Hum…but, let’s treat the rest of the parameters equally.

The query is properly validated by checking if it begins with the string “SELECT”, just employing a regular expression. Lastly, the number of records per page is verified to be a positive integer value.

That’s all about it. The constructor has happily performed the setting operations for the parameters, and its job is done. Having the “MySQLConnector” object living peacefully inside the class, we’re able to call its methods to build a dynamic output and show the paging links. That’s the task we’ve delegated to the other class method: “displayRecords()”. Join me in the next section to see how it works.