Active Frequency » Blog

The next version (1.3) of Django was just announced, and there are tons of things we here at Active Frequency are very excited to see. Some of these are just plain awesome. And, some scratch itches we’ve had on some of our projects.

But there are two warnings you need to pay attention to if you are considering going with 1.3; 1) CSRF is now required for all ajax calls, and there are some helpful code bits in there to make this an easy addition, and 2) 1.3 is the last version that will support python 2.4. Now let’s get on with the good stuff we are excited about:

• Backend support for Inactive users is going to be very helpful. There are some tricks, and I’ve done some of them, to create active users without proper usernames and passwords. Doing it that way is just strange, and this addition will provide the proper support for it.
• Include and With just got a lot more powerful in templates. This will allow you to create more modular and re-usable templates without worrying too much about template variables in your views.
• In the department of awesome, responses will now be available to decorators/middleware. I can think of a few places in our applications that would benefit by template switching located outside the view specifically.
• This is the feature that most people have been waiting on – and on the dev mailing list, talking about – Class Based Views. At first I wondered how much this would really change things, as the views I now write are very small and fairly boilerplate. However, in looking at the generic classes and examples they have I am excited to dig into this and have to write even less view code. With these kinds of developments all the stuff you hear about Javascript being the next language you must learn – they are right. More than half of the code I write these days is Javascript anyhow. Class-based views are only going to push development more in that direction.
• Two additions were made to i18n for helping translators in the new version (something we have worked with it quite a bit). First are Contextual Markers so you can give more information about what the word actually denotes. And second, comments built right into python comments. I wish I had these already, as we’ve already been in discussing and trying to make schemes to help the translators know exactly what we’re trying to get across.

The Django dev team is fantastic to get this much stuff out the door for version 1.3. You can see the whole changelog here. We here can only wait to see what they have in store for the future. And if you want to see what they’re working on for the future, sign up for the dev mailing list.

If you have ever written a thoroughly internationalized project you know just how hard it can be. While Python and Django are fantastic in allowing internationalization in your applications, sometimes we still need a little more help.

In the last post Kevin told showed us django-rosetta and a way to package and deploy the translation files. That is certainly one step. I have been a part of a team responsible for a PHP product with support for at least six languages. It got pretty hairy without a tool like django-rosetta and a sane deployment process.

In the Django world, the community is a huge resource – not just for advice and documentation, but also pluggable applications you can use in your projects. One of these we use pretty frequently is django-faq for creating an easy to update, index, and change FAQ system without a client writing tons of HTML. In case you think you are seeing a theme here, well, you are – we are working on an internationalized project. So we had another opportunity to contribute back to the community by internationalizing the django-faq app with the help of the already awesome multilingual-ng app. All in all a very small tweak for us to do – but now with one more fully internationalized app in the tool belt, it’s easier to internationalize the next project. I hope it helps more than just us!

If you’ve never worked with multilingual-ng in models, I’ll give a quick run-through here with the Topic model (but you can see all the basic changes I made in this diff).

1
2
3
4

class Topic(models.Model):
     # normally your name field would go here, but to make it translatable you do this
     class Translation(TranslationModel):
           name = models.CharField(max_length=150)

The rest of the work is magic. And there is an admin class built to handle the display and saving of this as well. It plugs right into the Django ORM. Beautiful!