Django - Tips to avoid repeating code in views

I'm moving from a PHP background into Django development via python, mostly for the sake of tackling a MVC (or MVT开发者_运维百科) that I feel makes the most sense, although in this pattern I've started to notice a lot of repeated code in my views.

For example, when logged in I have information regarding the user that I would like to appear on every page, although when using render_to_response and in every view this is required I have to grab the information and pass it to the render_to_response function.

I'm wondering what would be the most efficient way to cut down on the duplicate code which would in essence be required in all views in a particular app.

Thanks in advance.

---

Personally I am a huge fan of decorators, which are a python feature that isn't specific to Django. Decorators are the perfect syntactic sugar on top of higher-order functions, and they're especially useful for reducing boilerplate in views -- you can quickly define a generalized wrapper function, in which you can put the repetitive code for easy reuse and convenient one-stop refactoring.

It's probably easier to show you than explain how they work. Here is a simplified view example:

def listpage(request):
    return HttpResponse(render_to_string("itemlist.html", {
        "items": Item.objects.filter(visible=True).order_by("-modifydate")
    }))

def itemlist_tags(request, tags):
    return HttpResponse(render_to_string("itemlist.html", {
        "items": Item.objects.tagged(name=tags).filter(visible=True).order_by("-modifydate"),
    }))

... but then say you wanted to make these pages require the user to log in. You might add login code like so:

def listpage(request):
    if not request.user.is_authenticated():
        return f(request, *args, **kwargs)
    else:
        return HttpResponse(render_to_string("itemlist.html", {
            "items": Item.objects.filter(visible=True).order_by("-modifydate")
        }))

def itemlist_tags(request, tags):
    if not request.user.is_authenticated():
        return f(request, *args, **kwargs)
    else:
        return HttpResponse(render_to_string("itemlist.html", {
            "items": Item.objects.tagged(name=tags).filter(visible=True).order_by("-modifydate"),
        }))

... which is starting to get notably bigger and repetitive, even for a contrived example. You can make your functions slim again with decorators, like so:

from decorator import decorator

@decorator
def loginrequired(f, request, *args, **kwargs):
    if request.user.is_authenticated():
        return f(request, *args, **kwargs)
    else:
        return HttpResponseRedirect("/")

@loginrequired
def listpage(request):
    return HttpResponse(render_to_string("itemlist.html", {
        "items": Item.objects.filter(visible=True).order_by("-modifydate")
    }))

    @loginrequired
def itemlist_tags(request, tags):
    return HttpResponse(render_to_string("itemlist.html", {
        "items": Item.objects.tagged(name=tags).filter(visible=True).order_by("-modifydate"),
    }))

@loginrequired
def another_such_function(request):
    (...)

@loginrequired
def and_again(request):
    (...)

What happens is the decorator function is executed at the time of the function's definition. The 'f' in my example is an object representing the function that the decorator is applied to, which you can manipulate in unending ways.

This requires the decorator library, which is free on PyPI as are many good python morsels, you'll find.

You don't need the this library to write decorator functions, but it's helpful, especially in the beginning. They can do a whole lot more -- any callable can be a decorator; you can decorate class methods and intercept the self variable; decorators can be chained up, like so:

@second
@first
def originalfunction(*args):
    (...)

I'll leave the exploration of what you can do with such easy higher-order function manpipulation for you, should this notion whet your appetite. I have many more examples as well, for you or any other curious new python aficionados. Good luck.

---

Encapsulate the common code in a function and call it from different views. Sounds trivial, but it's the solution for 99% of such needs.

For a more specific answer, you'll have to show a more concrete example of the code you want to run.

---

There are two main ways for abstracting out common content.

Context processors are best for passing bits of data that you know you will need on every single view.

Template tags - especially inclusion tags - are useful for rendering separate areas of the page that will be the same on several templates.

---

Also, don't forget about generic views! In 90% of cases you can wrap object_list or object_detail and save yourself some code.