We often want to control the appearance of the output generated by an SQL query. In our case, this is not only necessary, but mandatory. While prior methods presented in previous articles have addressed this topic very basically, it's time to define a way to do visual presentation.

There are numerous ways to achieve this, all of them perfectly good and valid. Regarding our class, I've decided to define a generic template file, which allows us to specify the look of the records retrieved after performing the query. The template file will include a header section, a content section that contains the placeholders to be replaced by real values, and finally, a footer section. Here's how a sample template file would look:

<table><tr><td>First Name</td><td>Last Name</td></tr>

<tr><td>{data0}</td><td>{data1}</td></tr>

</table>

As you can see, the file contains only three lines. The first line contains a <table> tag; its first row is the header section. It enables us to specify a header element for the records. Notice that I've defined two table cells including "First Name" and "Last Name" as possible values to be retrieved from the database.

The middle line contains the placeholders to be filled with real values in the form {data0}, {data1}…{dataN}. So, if we're pulling out values from a table with information about famous writers (not my case, by the way), the final formatted output to be shown in the browser would look similar to this:

<table><tr><td>First Name</td><td>Last Name</td></tr>

<tr><td>Stephen</td><td>King</td></tr>

<tr><td>Dean</td><td>Koontz</td></tr>

<tr><td>Frank</td><td>DeFellita</td></tr>

---

</table>

Are you getting the idea? Fine, let's show another sample template file, this time using unordered lists to format records:

<ul>

<li>{data0}&nbsp;{data1}&nbsp;{data2}</li>

</ul>

In this case, we used regular HTML lists to control the record's visual presentation. Now I think that you understand the concept behind the template file system. Just feed the class with different template files, and voila! We've easily and quickly changed the appearance for any database generated output. The only requirement to keep in mind is that our template files must be three lines long. The first line is for headers, the second is for placeholders, and the last is for the footer. Isn't it simple?

Having explained the mechanism for record template files, it's time to look at the appearance of paging links. The technique for handling this is a lot easier. Since we don't need header or footer sections for displaying links, we simply provide them with an ID attribute, in order to tie them to a CSS style.

As stated before, the look and feel might be achieved by hard-coding templates outside the class and then passing them as parameters, possibly stored in PHP constants. While this might be easier to get done eventually, using template files gives us much more flexibility.

Our next step is to add the reviewed parameters to the constructor and include them as class properties. This way, our class is rewritten as follows:

class Pager {

var $conId; // connection identifier

var $query; // query performed

var $numRecs; // number of records per page

var $output; // output for records and paging links

var $template; // records template file

var $linksId; // Id attribute for styling paging links

function Pager(&$conId,$query,$linksId,$numRecs=10,$template=
'default_record_template.htm'){

// 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 linksId

(!is_numeric($linksId))?$this->linksId=$linksId:die('Invalid ID for paging links '.$linksId);

// validate template file

(file_exists($template))?$this->template=$template:die('Invalid template file '.$template);

// 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

}

}

Certainly, the constructor remains nearly the same. We've only added the extra parameters, specifying a default records template file called "default_record_template.htm", and validating them accordingly. For the supplied template file, the method checks whether the file exists. If it does, then it is assigned as a property. Otherwise, the script is stopped. Similarly, we're more permissive about ID values for paging links, allowing only non-numeric values.

Finally, the constructor has performed the proper validation on each incoming parameter and assigned properties. What comes next? Our "displayRecords()" method is waiting for a decent explanation. That is what we shall focus on now.