A couple updates

December 9, 2007    Django, Meta

Today marks two releases, both numbered 0.4, of django-registration and template_utils.

The new release of django-registration is largely a matter of policy; there’s no new functionality or features, but there is one backwards-incompatible change: the validation of passwords (verifying that the same password is entered in both fields) has been moved to the clean() method of RegistrationForm, which means that the error message from a password mismatch is now accessed via form.non_field_errors() instead of form.errors[‘password2’]. It’s a relatively easy change to make in your templates, but because it’s backwards-incompatible I’m pushing the version number up by one.

Also included in the 0.4 release of django-registration are two new translations: Greek and Russian, courtesy of Panos Laganakos and Ilya Filippov.

Updates to template_utils

This one is a bit larger in scope. First off, the Subversion trunk of template_utils has been Unicode-ready for quite some time now, but I’d never gotten around to rolling a release from that. Also, the apply_markup template filter has been updated to handle Django’s template autoescaping — the result of apply_markup is now marked as “safe” so that autoescaping won’t try to mess with the generated HTML. And in one final update to accomodate changes in Django trunk, where applicable the tags it provides have been updated to use the new Variable class for template variable resolution.

There’s also been a bit of internal rearrangement. The GenericContentNode class introduced in the previous release now lives in template_utils.nodes along with another useful Node subclass: ContextUpdatingNode, which simplifies the process of returning values into a template context. The general idea is that subclasses of ContextUpdatingNode define a method called get_content(), which returns a dictionary; the dictionary will then be used to update the template context.

Finally, there’s a new tag library included, which has two tags designed to simplify including RSS or Atom feeds in a Django template: include_feed and parse_feed. Both require the Universal Feed Parser library, and they differ only in how they return the results:

• include_feed uses a second template to render the feed’s items for eventual display.
• parse_feed simply drops the parsed feed object into your context.

The result is that you can do things like this (this example would fetch the feed of latest entries from this blog, and display the title of each along with a link):

{% load cache %}
{% load feeds %}
{% cache 3600 parsed_b_list_feed %}
{% parse_feed "http://www.b-list.org/feeds/entries/" as b_list_feed %}

<ul>
{% for entry in b_list_feed.entries %}
<li><a href="{{ entry.link }}">{{ entry.title }}</a></li>
{% endfor %}
</ul>
{% endcache %}

If you use these tags, do not even consider doing so without also using Django’s template fragment caching to cache the results from using these tags; pounding away on somebody’s feed with every single page view to your own site will get you in trouble.

The code in template_utils is based on a similar tag posted to djangosnippets, though it has a few more features and implements parse_feed as a ContextUpdatingNode.

As always

Report bugs through the Google Code issue trackers. I’ve done some tests locally, but haven’t yet had time to work up a full unit-test suite so there may well be problems. I’ll do my best to respond to them in a timely fashion.