HomePHP Page 4 - Previous or Next? Paginating Records with PHP - Part 3
Going deeper: a detailed coverage at the "displayRecords()" method - PHP
In part three of our series about paginating records with PHP, we will learn how to make our application work with a relational database system such as MySQL. We will develop a tight, compact PHP class, capable of performing the most common paging tasks efficiently.
Undoubtedly, the "displayRecords()" method is the real workhorse of the class, since it performs the hard work of building the SQL query, obtaining a formatted result set, and creating the paging links. While this might sound complex, the truth is that the process is quite simple.
Based on the previous "Pager" class, defined in the second part of this series, the method uses the same logic, accepting only one parameter: $page, which simply behaves as a page pointer for displaying records in a paginated manner.
Taking into account that the constructor has already set up the $query property, it's relatively easy to build dynamically a new query, adding a regular LIMIT clause to specify the offset and the number of records extracted from the database. So, let's put theory to the side for a moment and show the initial definition for our "displayRecords()" method:
As the above code clearly shows, the method is fed with the "$page" page pointer. Then, it calculates the total number of records extracted, performing the query without any LIMIT clause, and later using the "mysql_num_rows()" PHP function. The reason for doing this should become clear, because we need to calculate the number of pages needed to span all of the records. If the method cannot obtain this value, the class is simply stopped.
The next step logically involves calculating the number of pages to span the whole result set. It means simply dividing the total number of records by the number or records per page. Once this is done, the result is rounded up to work with an integer value.
Finally, having obtained these values, the method is capable of performing a strong validation process on the $page pointer, allowing only an integer positive value, which is always less than the number of pages previously calculated. If the page pointer is not within the valid range, for any given reason, then we place it at the first page ($page=1). Here's the code to validate the page pointer:
I briefly explained the reason for this in the second part of the series. Why should we bother validating this parameter? The answer is straightforward: we don't want any malicious code injected into the querystring, troubling our result sets or even the paging links. As with any parameter coming from GET, POST methods, it must be properly checked and validated. While this sounds like common sense, there are lots of sites that are extremely vulnerable to querysting manipulation, to name just one security failure. So, always keep an eye on that, and remember that the Internet is largely out of your control!
Back to our method explanation, the only remaining step is to perform a SELECT query appending a usual LIMIT clause, to obtain the specified number of records to be displayed at a time. The line listed below does that:
Now we've obtained the proper result set, ready to be displayed before the visitor's eyes. However, the method is still immature in its current version, since we have not used the template file to replace the placeholders and give our records the desired look. What's more, we need to include the paging links in the final output. The method must be completed. Let's move on and show how to work with the template file and our paging links.