A template tag for listing/linking to nearby pages in pagination should be provided.

[Grimboy]

object_list should pass a list of pages nearby so an index of links can be created. A list of links to pages near by the current page are is a common feature of pagination. So it seems sensible to implement it in this generic view. I understand generic views are meant to be simple but the majority of pagination has this feature and I would count it as a core feature of pagination.

[Gary Wilson <gary.wilson@…>]

This seems like something that would make a nice template tag, instead of changing stuff in the generic view.

[frankie@…]

Thanks your thoughts. I'm inclined to agree. It does perhaps seem a little out of place in the generic view.

As for a template tag. Which of these do you think would be better?

<ul>
    {% pagelist as page_list surround 5 %}
    {% for page_num in page_list %}
        <li>{{ page_num }}</li>
    {% endfor %}
</ul>

Or

<ul>
    {% pagelist as page_num surround 5 %}
        <li>{{ page_num }}</li>
    {% endpagelist %}
</ul>

Which could be expanded to optionally include the first few and last few page numbers (at the edges).

<ul>
    {% pagelist as page_num surround 5 edges 3 %}
        <li>{{ page_num }}</li>
    {% seperator %}
        <li>...</li>
    {% endpagelist %}
</ul>

I'm inclined towards the second but perhaps it's a bit weird or over the top. Please let me know what you think. Thanks.

[Gary Wilson <gary.wilson@…>]

Well, I was thinking it could be a one liner, something like:

{% pagelist surround 5 edges 3 firstlast true %}

Of course the options would have to be worked out, but then this would use a template to display, something like:

<ul class="pagelist">
    {% if firstlast %}<li><a title="First">&lt;&lt;</a></li>{% endif %}
    {% for p in pages %}
    <li{% ifequal p page %} class="current"{% endifequal %}><a title="Page {{ p }}">{{ p }}</a></li>
    {% endfor %}
    {% if firstlast %}<li><a title="Last">&gt;&gt;</a></li>{% endif %}
</ul>

Basically, some generic template that could serve as a good default. If someone wanted to customize it, they could just override the template with one of their own.

As far as the URL target to use for the links, maybe the tag would default to using a page query string parameter, so

<a href="?page={{ p }}">

Otherwise you could specify a URL prefix in the template tag, like

{% pagelist urlprefix page %}

which would become

<a href="../{{ urlprefix }}{{ p }}">

if the prefix is relative, or

<a href="{{ urlprefix }}{{ p }}">

if the prefix is absolute.

[frankie@…]

Proofread the documentation

[James Bennett]

There are a ton of different snippets floating around for doing this sort of thing; I'm going to tag with the sprint keyword to get some attention here to make a decision.

[frankie@…]

Fixed stupidity.

[James Bennett]

See alternate proposal in #4809, which was closed in favor of doing the work here.

[deepak <deep.thukral@…>]

IMO this patch needs better querystring parsing like /page?q=searching&highlight=cool&page=1 .. here is a snippets which might help frankie ​http://dpaste.com/17864/ and here is discussion on it ​http://groups.google.com/group/django-developers/browse_thread/thread/93646ef6a168ad6a/1bb42300896b1403

[frankie@…]

Yeah, I though about that. The only problem is that as soon as you add that you have the requirement for the template context processor django.core.context_processors.request because the only way for a template tag to get access to the request.querystring. (Well unless you add a middleware component and use thread local storage, but that's hardly an appetising proposal either.) The case of wanting to use a get key-value pair for the page (page=foo) and already having a bit of querystring going is not too hard to handle though. Each page in page_index has {{ page.number }} which can be used in combination with querystring parsing in the view to create a link in a pagelist template.

[James Bennett]

See also #5425, which I'm consolidating here temporarily so we have a single place to handle pagination discussions.

[Petr Marhoun <petr.marhoun@…>]

#5425 is not about pagination so I reopened it.

[Jacob]

The page object introduced in [7306] fixes this.

[Jacob]

Er, no, it doesn't.

[Russell Keith-Magee]

Marking this wontfix; there's nothing wrong with the principle of making the common use case of pagination easier to use, but this isn't it. The template example in the provided docs should be enough to convince anyone of that. This can be revisited if someone can present an implementation that is in the wild and is getting some public use.