Django 1.3 First Impressions

On the whole I am very pleased with Django 1.3.  The developers did a good job of taking care of some of the outstanding warts in Django, particularly the lack of “static file” management.  While I have not yet used the django.contrib.staticfiles app, it appears to solve the problem in a reasonable way.  Now I can retire the workarounds (such as this) that I had developed to deal with the problem.  The addition of built-in logging support is certainly welcome.  Improving and fixing inconsistencies in certain template tags all seems good.  I previously praised the render() shortcut, which will eliminate the repetitive nonsense of render_to_response(context_instance=RequestContext(request)).  The ORM got an important patch allowing configuration of on-delete behavior for ForeignKey (and OneToOneField) fields, about which I had also posted.  One interesting, small, but nice improvement came unannounced: help_text on a form field is now wrapped by a <span></span> when rendered as HTML by the as_*() methods.  I actually filed a ticket reporting this omission from the announcement.  For some reason, it seems that getting this change into the code and documentation has been a challenge.

I suspect there may be some moaning around the deprecation of function-based generic views in favor of class-based views.   Class-based views make sense, but it looks like there will be a little pain in the transition, partly because the keyword arguments for Django’s built-in generic view functions don’t map exactly to the generic view class keyword arguments.  It would have been nice to provide a little smoother transition there.  Also, the class-based view documentation is rather dense because you have to refer to the mixin classes that compose the actual generic view class you want to use.  I’m sure it will get easier with time, but it does feel like a jump in complexity that could make generic views more difficult for new users.    For example, where I did this before in a URLconf module:

from django.conf.urls.defaults import *
from django.views.generic.simple import direct_to_template

urlpatterns = patterns('',
    (r'^status/$', direct_to_template,
     {'template': 'sitetest/status.txt', 'mimetype': 'text/plain'}),
)

I now have to do something like this:

from django.conf.urls.defaults import *
from django.views.generic.base import TemplateView

class PlainTextTemplateView(TemplateView):
    """A plain text generic template view."""
    def render_to_response(self, context, **kwargs):
        return super(PlainTextTemplateView, self).render_to_response(
            context, content_type='text/plain', **kwargs
            )

urlpatterns = patterns('',
    (r'^status/$', PlainTextTemplateView.as_view(template_name='sitetest/status.txt')),
)

While class-based views may have been a step in the right direction for the framework, I wonder how it will play out.

Advertisements
  1. #1 by Tim on April 4, 2011 - 7:26 am

    Nice review.