How does this module compare with Custom pagers, and does it duplicate functionality?

I've not looked at the code, but reading the project page I think the lookup table idea is a good one; custom pagers suffers from overhead issues of having to check any single node for membership of all pagers.

Might it be an idea to try to work this caching approach into Custom Pagers if the overall aim of both modules is similar? That already has systems for choosing a node set from views, for theming, and so on.

Comments

jcnventura’s picture

Looking at it, the Custom Pagers is more mature (i.e. not simply an API) and a lot more popular.

A merge might actually be a good idea. It would eliminate the requirement for the Views module in Custom Pagers for simple per-content type prev/next navigation, and improve performance A LOT. For those wanting to work with more flexible options, my patch in #662362: Previous/Next for a Views list could be adapted.

I will take a deeper look at the Custom Pagers module.

João

bhosmer’s picture

Issue summary: View changes
Status: Active » Closed (works as designed)

Custom pagers indexes the nodes on page load. It can be beneficial for sites with a smaller number of nodes.

This module indexes in batches during a cron run and is more suitable to sites with a high number of nodes which the performance impact would be noticeable during each page load.