This is a function wrapping the code from [example](http://docs.djangoproject.com/en/dev/topics/pagination/#using-paginator-in-a-view) from django docs.
The required parameters are: `request` which is a `Request` object from a view, and `objects` - a list of objects to paginate.
You may want to tune number of items per page by specifying `count` and the name of a GET parameter through `param_name`
To use it in your view just wrap the paginated object into a function for example:
def someview(request):
articles = Article.objects.all()
... some other logics ...
return render_to_response(template, {'articles': paginate(request, articles)}
Example Usage of [Very basic CouchDB Paginator](http://www.djangosnippets.org/snippets/1208/)
An Example setup of CouchDB with django can be found at:
[Eric Florenzanos post about django+couchdb](http://www.eflorenzano.com/blog/post/using-couchdb-django/)
This is a very basic paginator for CouchDB ViewResults.
It's usage is similar to the django one.
**CouchPaginator** is almost like the django version with one exception: It's constructor needs an additional argument `pages_view` which is either a reduce result or an integer which holds the total number of objects across all pages.
*Example Map/Reduce for pages*:
> map = function(doc) {
> if(doc.type=="application" || doc.type==\"inquiry\"){
> emit([doc.meta.user.toLowerCase(), doc.type], 1);
> }
> reduce = function (doc, value, rereduce){
> return sum(value);
> }
**SimpleCouchPaginator** is much simpler and needs no total number and can only paginate by "next" and "previous" page. Use this if you don't have an reduce view which tells you the amount of total object.
An Example setup of CouchDB with django can be found at:
[Eric Florenzanos post about django+couchdb](http://www.eflorenzano.com/blog/post/using-couchdb-django/)
[See example usage](http://www.djangosnippets.org/snippets/1209/)
A subclassed version of the standard Django Paginator (django.core.paginator.Paginator) that automatically caches pages as they are requested. Very useful if your object list is expensive to compute.
MIT licensed.
This is an updated version of http://www.djangosnippets.org/snippets/628/ now working with Django's new Paginator class, instead of the deprecated ObjectPaginator.
See: http://blog.elsdoerfer.name/2008/05/26/diggpaginator-update/
**Paginator TemplateTag**
TemplateTag to use the new Paginator class directly from a template.
The paginate template tags take the following options:
1. list or queryset to paginate
2. number of pages
3. [optionaly] name of the Paginator.Page instance; prefixed by keyword 'as'
4. [optionaly] name of the http parameter used for paging; prefixed by keyword 'using'
If you want to specify the parameter name with the keyword 'using' you must use the 'as' keyword as well. The default name of the paging variable is "page" and the paginator (the class that knows about all the pages is set in the context as "page_set". This follows the naming scheme of the ORM mapper for relational objects where "_set" is appended behind the variable name.
Usage, put the following in your template:
{% load paginate %}
{% get_blog_posts blog_category as posts %}
{% paginate posts 10 as page using page %}
<ul>
{% for post in page.object_list %}
<li>{{ post.title }}</li>
{% endfor %}
</ul>
<div>
{% if page.has_previous %}
<a href="?page={{ page.previous_page_number }}">previous</a>
{% endif %}
<i>{{ page.number }} of {{ page_set.num_pages }}</i>
{% if page.has_next %}
<a href="?page={{ page.next_page_number }}">next</a>
{% endif %}
</div>
The templatetag requires the request object to be present in the template context. This means that you need 'django.core.context_processors.request' added to settings.TEMPLATE_CONTEXT_PROCESSORS list or otherwise make sure that the templatetag can access the request object.
Comments are appreciated.
**This code will throw deprecation warnings in newer Django checkouts - see the http://www.djangosnippets.org/snippets/773/ for an improved version that should work with the recent trunk.**
objects = MyModel.objects.all()
paginator = DiggPaginator(objects, 10, body=6, padding=2, page=7)
return render_to_response('template.html', {'paginator': paginator}
{% if paginator.has_next %}{# pagelink paginator.next #}{% endif %}
{% for page in paginator.page_range %}
{% if not page %} ...
{% else %}{# pagelink page #}
{% endif %}
{% endfor %}
http://blog.elsdoerfer.name/2008/03/06/yet-another-paginator-digg-style/
Date-based generic views do not provide pagination by default but Django is very extensible. It provides a Paginator that takes care of pagination. Since date based views usually order by descending order ie from latest entry to the oldest, I used a queryset to order the items (on a field called 'date_pub') and then pass this queryset to the paginator which takes care of the pagination.
Generate a list of page links like:
First Prev 1 2 3 *4* 5 6 7 Next Last
To use:
1. Put Paginator.py into your app directory
2. Copy pagination.html to your templates directory
3. pass a paginator object to your Context
4. include the pagination.html template on the page you wanted paginated
Feel free to send ideas for improvement. If enough people ask, I'll package this as a single app and perhaps even make the template inclusion into a templatetag for even easier use.
**Problem**:
You search by firing POST and paginate by firing GET, so search results disappear on GET. I want to preserve searching results, so user can paginate them.
First I try to use some static class to keep search results, but this solution has bug (thanks to svetlyak). In multiuser environment other user searching got results from previous one. No @cache_control(private=True) helps so I decided to change searching schema by using GET in the first place and to supply query string on each 'paging' request. Also added some memory cache that expires after 5 min
**In template**
Please append query to each paging link:
<a href="?page={{ page_number }}
&search_query={{ query|urlencode }}">
{{ page_number }}</a>
This snippet should keep search results on pagination in multiuser environment.
Piggybacks on the pagination-related template context variables provided by the `object_list` generic view, adding extra context variables for use in displaying links for a given number of pages adjacent to the current page and determining if the first and last pages are included in the displayed links.
Also makes it easy to implement consistent paging all over your site by implementing your pagination controls in a single place - paginator.html.
Optionally accepts a single argument to specify the number of page links adjacent to the current page to be displayed.
Usage:
`{% paginator %}`
`{% paginator 5 %}`