views:

228

answers:

4

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.

+2  A: 

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.

Eli Bendersky
+1  A: 

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.

Daniel Roseman
+3  A: 

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

Dmitry Shevchenko
+3  A: 

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.

fish2000
By the way, the 'tagged()' function in the second fake view is not a typo; it's a simplified interface I wrote to the django-tagging app, also in the name of boilerplate-reduction, which the curious will find here: http://www.djangosnippets.org/snippets/1942/
fish2000
Very helpful, thanks, decorators appear to have a lot of extra uses for me.
D Roddis