Python and Django Stuff

I usually come at a new language or framework with something small to accomplish. I have some idea of how to accomplish it in my primary language or framework so I use that vernacular to find out how to do what I want in the new language or framework. I know what a list is and how to use one. So, I look for the equivalent functionality in the language I am experimenting in. And so on. Same for frameworks. However, the django docs are not so overwhelming that you can’t read through them in a single sitting and I would advise you do so if you are interested in using django beyond the Polls tutorial. It gives you a base. It will take your mind in directions you hadn’t considered because you were using the context of another language or framework to formulate your ideas and how to implement them.

I have spent a lot of time with Django here of late. Some of them in a highly frustrated state. The difference, I believe, between Django and Zope/Plone (other than the obvious difference in purpose between the two) is that Plone gives you a lot out-of-the-box and in my experience, things work as you expect them to. Not entirely so with Django. Much of that is my ignorance with a new system, some of that is the immaturity of the project’s exposure to the general public where the issues are quickly discovered and some of that is use of voodoo by way of metaclasses used heavily in Django. On this latter point, I’m not sure how you would create such a framework without them.

Having said that, the real difference, for me anyway, is that you can actually grok through the code and using pdb and other technique, you can figure out where you are and where your going. Certainly you can do this with Plone; however, once you get there you can’t be convinced you know where the hell you are.

Django has a small footprint and a focused purpose. I am finding that refreshing. I am by no means as productive with it yet versus Zope, but I can see that I am getting there. One other surprise I found was how much I really don’t like ZPT. I can’t exactly articulate the reasons for this. Maybe it is just change of pace but once I began utilizing Django’s templating system I felt in some sense freed. I also like its limitations regarding python: calls in ZPT.

This wasn’t obvious to me and there is likely an easier way to get this done but… you can add the paging of the admin screens to your main templates by utilizing the ObjectPaginator. The generic view provide this free of charge w/out having to do anything, but your own pages don’t (AFAIK).

from django.core.paginator import ObjectPaginator, InvalidPage

Then get the paginator object:

paginator = ObjectPaginator(products, {’offset’:12} , paginate_by)

sending it the object, an offset and the number to page by. Next, you want to get the current page (if there is one):

page = int(request.GET.get(’page’, 0))

paginator will expose a number of function to control paging. You will then want to pass these on to your template.

def index(request):
paginate_by = 20
paginator = ObjectPaginator(products, {’offset’:2} , paginate_by)
page = int(request.GET.get(’page’, 0))
prods = paginator.get_page(page)
t = template_loader.get_template(’products/products_list’)
c = Context(request, {
‘prods’: prods,
‘is_paginated’ : True,
‘results_per_page’ : paginate_by,
‘has_next’: paginator.has_next_page(page),
‘has_previous’: paginator.has_previous_page(page),
‘page’: page + 1,
‘next’: page + 1,
‘previous’: page - 1,
‘pages’: paginator.pages
})
return HttpResponse(t.render(c))

Now in your template you can do something like this:

{% if has_previous %} <a href="?page={{ previous }}"> < < previous {{ page }} {% if has_next %} <a href=”?page={{ next }}”> next >> {% endif %}