[patch] django.views.generic.list_detail.object_list - add context variables on pagination

[Max Derkachev <mderk@…>]

The patch is for django.views.generic.list_detail.object_list and the docs.
It adds the following variables to context, when the paginated object_list is required:

1. pages_list - the list of page numbers;
2. page_start - the number of the first item on the page;
3. page_end - the number of the last item on the page.

They are obviously missing, and are very useful when one need to construct pagination control like this:

PREV 1 2 3 4 5 6 7 NEXT
showing 10-20 of 100 items

the template source will be like this:

<a href="#">PREV</a>
{% for page_num in pages_list %}
{{ page_num }}
{% endfor %}
<a href="#">NEXT</a>
showing {{ page_start }}-{{ page_end }} of {{ hits }}

[Max Derkachev <mderk@…>]

The patch

[Gary Wilson <gary.wilson@…>]

I would say that all this stuff related to pagination needs to be contained in the ObjectPaginator class. This way it can get re-used in any other view and not just the object_list generic view. For example, allow ObjectPaginator constructor to be passed the page number, which would set, say, item_start, item_end, and pages attributes.

[Max Derkachev <mderk@…>]

Indeed, I missed the fact that ObjectPaginator has first_on_page and last_on_page methods.
So, I updated the patch and added one property to ObjectPaginator to get the list of page numbers.
I've also changed the names of variables to more meaningful.

The subtle problem is that ObjectPaginator uses 0-based page number (the view uses 1-based), and one that uses it should always remember that when calling ObjectPaginator members.
E.g. the constructor is called with page - 1 from the view.
So, to get first_item, the view should call them as paginator.first_on_page(page - 1).
But I guess that should not chnange since it may break BC, if somebody uses ObjectPaginator in custom views.

[Max Derkachev <mderk@…>]

the better patch

[frankie@…]

Dupe of #3169 and #3170.