Holy Paginator, Batman!

posted: 2007-03-28 03:08:08 perma-link, RSS comments feed

Django has a really great pagination framework built in, but it does encourage you to write code like:

entries = MtEntry.objects.filter( entry_status__exact = 2).order_by( '-entry_created_on' )
paginator = ObjectPaginator(entries, 5)
page = int( request.GET.get('page', 1) )
object_list = paginator.get_page(page - 1)
c = RequestContext(request, {
'%s_list' % template_object_name: object_list,
'is_paginated': paginator.pages > 1,
'results_per_page': paginate_by,
'has_next': paginator.has_next_page(page - 1),
'has_previous': paginator.has_previous_page(page - 1),
'page': page,
'next': page + 1,
'previous': page - 1,
'last_on_page': paginator.last_on_page(page - 1),
'first_on_page': paginator.first_on_page(page - 1),
'pages': paginator.pages,
'hits' : paginator.hits,
})

That's actually a little simplified -- it doesn't handle any cases where bad data was passed in, etc. I took that from the generic view code in django's trunk and cut it down. I just want to demonstrate how much the view writer needs to account for the work to be done in the template and the tip-toeing around off-by-one errors that have to be carefully avoided.

Here's what I've done to simplify that on my way to creating the holy grail of pagination productivity:


class pager( ObjectPaginator ):
def set_page( self, p ):
if p >= 0 and p < self.pages:
self.current_page = p
else:
self.current_page = 0
def this_page( self ):
return [ itm for itm in self.get_page( self.current_page ) ] # trn this from a set to a list
def has_next( self ):
return self.has_next_page( self.current_page )
def has_prev( self ):
return self.has_previous_page( self.current_page )
def next_page( self ):
return self.has_next() and self.current_page + 1 or 0
def prev_page( self ):
return self.has_prev() and self.current_page - 1 or 0

So now, my view code looks like:

entries = MtEntry.objects.filter( entry_status__exact = 2).order_by( '-entry_created_on' )
paginator = pager( entries, 5 )
paginator.set_page( int( request.GET.get( 'page', '0' ) ) )
c = Context( { 'entries': paginator.this_page(), 'paginator': paginator} )


and my templates look like:

<ul>
{% for item in paginator.this_page %}
<li>{{ item }}</li>
{% endfor %}
</ul>
<p>
There are {{ paginator.hits }} entries.
{% if paginator.has_prev %}<a href="?page={{paginator.prev_page}}">Previous</a> {% endif %}
{% if paginator.has_next %}<a href="?page={{paginator.next_page}}">More</a> {% endif %}
</p>

As you can see: very coder friendly and very template designer friendly. In fact, I can use that template as my jumping off point for any paginated list.

In general, my strategy is to make the view code responsible for fetching the core object(s) for a page and not worry about the details of the actual page. How pagination is handled is left up to the page designers who have now been given a tool for managing pagination. I believe my departure on this from the general django communities design patterns stems from most django work being handled by python developers, whereas I have an actual separation of python and template development.

---

Comments

Post a comment

Your name:

Comment: