In order to paginate items into pages, Zend\Paginator must have a generic way of accessing that data. For that reason, all data access takes place through data source adapters. Several adapters ship with Zend Framework by default:
|ArrayAdapter||Accepts a PHP array|
|DbSelect||Accepts a Zend\Db\Sql\Select plus either a Zend\Db\Adapter\Adapter or Zend\Db\Sql\Sql to paginate rows from a database|
|Iterator||Accepts an Iterator instance|
|Null||Does not use Zend\Paginator to manage data pagination. You can still take advantage of the pagination control feature.|
Instead of selecting every matching row of a given query, the DbSelect adapter retrieves only the smallest amount of data necessary for displaying the current page. Because of this, a second query is dynamically generated to determine the total number of matching rows.
To create an instance of Zend\Paginator, you must supply an adapter to the constructor:
In the case of the Null adapter, in lieu of a data collection you must supply an item count to its constructor.
Although the instance is technically usable in this state, in your controller action you'll need to tell the paginator what page number the user requested. This allows advancing through the paginated data.
The simplest way to keep track of this value is through a URL parameter. The following is an example route you might use in an Array configuration file:
With the above route (and using Zend Framework MVC components), you might set the current page number in your controller action like so:
There are other options available; see :ref:`Configuration <zend.paginator.configuration>` for more on them.
Finally, you'll need to assign the paginator instance to your view. If you're using Zend Framework MVC component, you can assign the paginator object to your view model:
The usage of most adapters is pretty straight-forward. However, the database adapter requires a more detailed explanation regarding the retrieval and count of the data from the database.
To use the DbSelect adapter you don't have to retrieve the data upfront from the database. The adapter will do the retrieval for you, as well as the counting of the total pages. If additional work has to be done on the database results which cannot be expressed via the provided Zend\Db\Sql\Select object you must extend the adapter and override the getItems() method.
Additionally this adapter does not fetch all records from the database in order to count them. Instead, the adapter manipulates the original query to produce a corresponding COUNT query. Paginator then executes that COUNT query to get the number of rows. This does require an extra round-trip to the database, but this is many times faster than fetching an entire result set and using count(), especially with large collections of data.
The database adapter will try and build the most efficient query that will execute on pretty much any modern database. However, depending on your database or even your own schema setup, there might be more efficient ways to get a rowcount. For this scenario, you can extend the provided DbSelect adapter and implement a custom getRowCount method. For example, if you keep track of the count of blog posts in a separate table, you could achieve a faster count query with the following setup:
This approach will probably not give you a huge performance gain on small collections and/or simple select queries. However, with complex queries and large collections, a similar approach could give you a significant performance boost.
The DbSelect adapter also supports returning of fetched records using the Zend\Db\ResultSet component of Zend\Db. You can override the concrete RowSet implementation by passing an object implementing Zend\Db\ResultSet\ResultSetInterface as the third constructor argument to the DbSelect adapter:
Now when we iterate over $paginator we will get instances of our custom entity instead of key-value-pair arrays.
The view script is used to render the page items (if you're using Zend\Paginator to do so) and display the pagination control.
Because Zend\Paginator implements the SPL interface IteratorAggregate, looping over your items and displaying them is simple.
Notice the view helper call near the end. PaginationControl accepts up to four parameters: the paginator instance, a scrolling style, a view script name, and an array of additional parameters.
The second and third parameters are very important. Whereas the view script name is used to determine how the pagination control should look, the scrolling style is used to control how it should behave. Say the view script is in the style of a search pagination control, like the one below:
What happens when the user clicks the "next" link a few times? Well, any number of things could happen. The current page number could stay in the middle as you click through (as it does on Yahoo!), or it could advance to the end of the page range and then appear again on the left when the user clicks "next" one more time. The page numbers might even expand and contract as the user advances (or "scrolls") through them (as they do on Google).
There are four scrolling styles packaged with Zend Framework:
|All||Returns every page. This is useful for dropdown menu pagination controls with relatively few pages. In these cases, you want all pages available to the user at once.|
|Elastic||A Google-like scrolling style that expands and contracts as a user scrolls through the pages.|
|Jumping||As users scroll through, the page number advances to the end of a given range, then starts again at the beginning of the new range.|
|Sliding||A Yahoo!-like scrolling style that positions the current page number in the center of the page range, or as close as possible. This is the default style.|
The fourth and final parameter is reserved for an optional associative array of additional variables that you want available in your view (available via $this). For instance, these values could include extra URL parameters for pagination links.
By setting the default view script name, default scrolling style, and view instance, you can eliminate the calls to PaginationControl completely:
When all of these values are set, you can render the pagination control inside your view script with a simple echo statement:
Of course, it's possible to use Zend\Paginator with other template engines. For example, with Smarty you might do the following:
You could then access paginator values from a template like so:
The following example pagination controls will hopefully help you get started:
The following options are available to pagination control view scripts:
|first||integer||First page number (i.e., 1)|
|firstItemNumber||integer||Absolute number of the first item on this page|
|firstPageInRange||integer||First page in the range returned by the scrolling style|
|current||integer||Current page number|
|currentItemCount||integer||Number of items on this page|
|itemCountPerPage||integer||Maximum number of items available to each page|
|last||integer||Last page number|
|lastItemNumber||integer||Absolute number of the last item on this page|
|lastPageInRange||integer||Last page in the range returned by the scrolling style|
|next||integer||Next page number|
|pageCount||integer||Number of pages|
|pagesInRange||array||Array of pages returned by the scrolling style|
|previous||integer||Previous page number|
|totalItemCount||integer||Total number of items|