From Views 3.x Roadmap:

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:

Any other ideas?

This patch needs a lot of work.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

merlinofchaos’s picture

Priority: Normal » Critical
Status: Needs work » Needs review

Upgrading. This one is also high on my priority list, especially now that we've made some improvements to plugins. This needs to be modernized somewhat. We can make this pretty awesome, I think.

dawehner’s picture

Here is a updated patch which moderize the options.

Additional it fixes some minor style fixes.

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.

merlinofchaos’s picture

This is still a little behind.

I got rid of all the get_*_plugin functions and now there's just get_plugin()

+  function init(&$view, &$display) {
+    $this->view = &$view;
+    $this->display = &$display;
+    $this->options = array();
+
+    if (is_object($display->handler)) {
+      // Note: The below is read only.
+      $this->options = $display->handler->get_option('pager');
+    }
+  }

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.

merlinofchaos’s picture

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.

Even without this, though, this patch should be pretty reviewable.

merlinofchaos’s picture

Status: Needs review » Fixed
FileSize
46.26 KB

Ok, addressed some of the remaining issues. I didn't add the "max # of pages" functionality yet, but it should be trivial to add with a later patch.

This is the patch I committed.

merlinofchaos’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
Status: Fixed » Patch (to be ported)

Duh. Attached the patch to mark it for 7.x porting.

dawehner’s picture

dawehner’s picture

dependense is away, sure.

dawehner’s picture

Status: Patch (to be ported) » Fixed

yyyyeah.

Patches worked, i tested quite a bit. And all simpletests are working also.

Status: Fixed » Closed (fixed)
Issue tags: -views 3.x roadmap

Automatically closed -- issue fixed for 2 weeks with no activity.