When I was nearly done with Views and I was playing with the AJAX stuff, I wanted a smaller pager to put into blocks, because the standard pager doesn't fit. And having AJAX in a block is really handy, so I added the mini pager. I should have simply made it a plugin, but not just on the output side, on the input side too. So that we can do more stuff with pagers. See my blog post on how we can fix the pager system. That can be applied to Views. Sure, it may not necessarily match the built in pager system, but if a site is mostly Views powered, then it may not matter too much, and the power and flexibility it provides could be really nice.

This is an initial patch. It provide pagers as plugins.

We have to:

See which pagers will be implemented as plugins: None, Mini, Full, Alpha?

One comment: Why is the pager element in full pager. I guess it should be in mini pager, too. The minipager is often used in blocks, and there the pager element is more important, because the main content could have a pager, too.

Setting $this->options = array() will undo the default settings from the construct. also unpack options isn't called. Check out the init() function from the exposed form plugin, it probably ought to be exactly the same.

We will probably need a 'type' on pagers. Since we're supporting multiple query backends. We probably need a 'type' on the query backends. For example, right now our query backend is 'sql'. All 'sql' query back ends would need to conform to certain things, including how to use the pager. Other backends may not. We should think about this, though. Come up with some use cases. What will change if we're using solr or flickr as the backend. Paging will definitely change.

I think all data relating to paging should move to the paging plugin:

items_per_page

offset

element id

Obviously we'll want more options, too. People really want to be able to say "up to X pages" and it's actually pretty easy once we take full control of paging.

This doesn't actually implement the paging, but my vision is that paging is more or less a case of the build() function calling $pager->query() which does whatever it is going to do to the query. Later on when executing the query, we give the pager an option to run a count if necessary, and we cease using db_query_range() and just add the LIMIT directly to the query. We could even make an add_limit() method to the query object to make this work better.

The only pager we should add would be a 'fuzzy' pager (not sure what to call it) that does not run a count, but instead fetches 1 more record than it displays and only contains a 'next' button. I'm sure Robert Douglass will have some input into how that should work, as he's been working with Very Large datasets where the count query is a major burden.

Ok, this is mostly complete. However, there are 2 items I can think of that I haven't done yet:

1) Doublecheck all references to $view->pager or the removed $view->*pager*() functions. Those no longer exist and won't be valid. I know that the global counter checks pager data and that the cache plugin checks pager data, so those two have to be updated.

2) Pagers can have their own themes. For example, the mini pager. These should be auto-registered much like they are for styles.

3) While we're doing this, I want to add a maximum page count to the full and mini pagers. It should be absolutely trivial.

4) The mini pager does not actually have to count. It just needs to bring in one more result than it will display. It can test for this extra result via post_execute() and if that extra result exists remove it and know that there is at least one more page.