SmileyChris has a possible implementation in ticket 2576 (http://
code.djangoproject.com/ticket/2576) but was marked wontfix so I
thought I'd bring the discussion here.
I can see the reasoning behind the wontfix, but I think in this light
it might be worth reviewing.
As Gary Wilson pointed out in 4805, this would mean we only need the
paginator object in the context instead of the present 11. It would
also make pagination easier to use in the date based generic views, if
desirable (ticket 2367), and easier to use in custom views too.
An alternative is to have an ObjectPaginatorWithPage class which
extends ObjectPaginator, and works in the same way as SmileyChris'
patch. The generic view(s) would be basically the same, except:
paginator = ObjectPaginatorWithPage(queryset, paginate_by, page)
and removing the other 11 lines of context variables.
Obviously this would be backwards incompatible for the templates.
I'm a fan of the paginator-class-with-page-state idea from ticket
2576, which is to say I disagree with the "wontfix." :-)
I completely agree that it makes things much simpler, especially for
generic views. In that case, we can simply pass a single PaginatorPage
(or some better name) object to the template, rather than having to
pass "page_number" and "has_next_page" and "has_previous_page" and all
that assorted malarkey.
holovaty.com | djangoproject.com
There are a couple of patches attached to #4805 to look at. One
modifying the ObjectPaginator class to add an optional page argument,
and one to add a new ObjectPaginator derived class based on #2576.
Another issue to consider is whether to use zero or 1-based indexing
for the page numbers.
>From a coding POV it should be 0-based, but from a template POV it
should probably be 1-based. The patch I added based on SmileyChris'
work uses 0-based to create the paginator, and 1-based to access the
page_number, next/previous_page_number properties (by default,
customizable using the base argument).
I can't decide if it should just stick to one or the other or not.