fidzu : django

Lately, we've been taking over projects from people who began building their first site in Django, but either got in over their head or just found they didn't have the time to continue. As I review the existing code, the first issue I typically see is using the render_to_response shortcut without including the RequestContext, preventing context processors from being used in the templates. The standard symptom is when people can't access MEDIA_URL in their templates.

Here are a few ways to add RequestContext to your templates.

Option #1: Adding RequestContext to render_to_response

The Django documentation recommends passing RequestContext as an argument to render_to_response like this:

from django.shortcuts import render_to_response
from django.template import RequestContext

def my_view(request):
    # View code here...
    return render_to_response('my_template.html',
                              my_data_dictionary,
                              context_instance=RequestContext(request))

This works, but as you can see, it adds a fair amount of repetitive code to your views.

Option #2: Wrapper for render_to_response

Don't repeat yourself. Create a wrapper like this, courtesy of Django Snippet #3

from django.shortcuts import render_to_response
from django.template import RequestContext

def render_response(req, *args, **kwargs):
    kwargs['context_instance'] = RequestContext(req)
    return render_to_response(*args, **kwargs)

Option #3: Use Generic Views

Django's generic views include RequestContext by default. Although the docs show them being used in urls.py, you can just as easily use them in your views. James Bennet gave some examples of this technique on his blog back in '06. It looks something like this:

from django.views.generic import list_detail

def my_view(request):
    # View code here...
    return list_detail.object_list_(request,
                                    queryset=Foo.objects.all(),
                                    extra_context=some_dict)

Most views can be distilled down to either a single object or list of objects with some extra variables thrown in. When they can't, simply use direct_to_template.

Option #4: Getting Creative with Decorators

I came across a technique I hadn't seen before a couple of days ago when poking around django-cashflow. It monkey patches render_to_response using option #1 above, then creates uses a decorator for it. The code looks like this:

def render_to(template_name):
    def renderer(func):
        def wrapper(request, *args, **kw):
            output = func(request, *args, **kw)
            if not isinstance(output, dict):
                return output
            return render_to_response(request, template_name, output)
        return wrapper
    return renderer

@render_to('my_template.html')
def my_view(request):
    # View code here...
    return some_dict

Pretty slick.

How About You?

I use generic views for a few of reasons.

• It is less verbose than option #1
• Options 2 & 4 are clever, but I prefer to use built-ins whenever possible. One of the reasons I chose Python over Ruby is because it isn't a TIMTOWTDI language. Wrappers and shortcuts are great, but they can also make it more difficult for someone else to jump into your code and start working. With generic views, you get sane defaults and everything is already fully documented and clear to other Django developers.
• They provide a standardized naming scheme for your templates. Again allowing other developers to jump right into your code without having to learn your style.

So how about you? What technique do you use and why?

17 Oct 2024 10:09pm GMT

Lincoln Loop has been in "head down" mode for the last couple months. In addition to being knee deep in client projects, we have grown from a one-man development studio to a full-fledged Django development shop/consultancy. We are proud to announce that Lincoln Loop is the first (that we know of) company focusing solely on Django application development. Our development team is currently five strong and oozing with talent. Each member contributes to the community in blog posts or open source add-ons; a few of us have contributed code to Django itself. More on our dev team in the near future.

We went through the typical growing pains during the transition, but the kinks are worked out and we can officially say that we are open for business. Django projects big and small, send them our way. Our devs can handle nearly anything.

• New Django projects based on your specs
• Existing projects when your developer doesn't have the time, doesn't have the expertise or just skipped out on you
• Scaling up your existing development team for large feature pushes
• Ellington customization

You name it, if it is Django related, we can probably help. Don't be shy, drop us a line.

17 Oct 2024 10:09pm GMT

This was a huge feat. Congrats guys! 1.0 here we come.

17 Oct 2024 10:09pm GMT