CalDAV is clearly the way to go, but as far as libraries go, the only one I’ve been able to find was CalDAVClientLibrary, which, quite frankly, scares me. I’m already familiar with CalendarServer, and I can’t qualify that as “lightweight”, “simple” or “easily installable”.

CalDAV

In case you don’t know what CalDAV is, it’s an extension to webdav for calendaring, and is defined in rfc4791. If you don’t feel like reading all of this, it’s mostly HTTP with XML requests and responses, but not always, which is why it gets kind of weird…

Example requests

Creating a calendar:

MKCOL /calendars/pythoncaldav-test HTTP/1.1
Host: example.com
Accept-Encoding: identity
Content-Length: 249

<?xml version='1.0' encoding='utf-8'?>
<D:mkcol xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
  <D:set>
    <D:prop>
      <D:resourcetype>
        <D:collection>
          <C:calendar-collection/>
        </D:collection>
      </D:resourcetype>
      <D:displayname>Yep
    </D:prop>
  </D:set>
</D:mkcol>

Deleting a calendar:

DELETE /calendars/pythoncaldav-test HTTP/1.1
Host: example.com
Accept-Encoding: identity

caldav

The version I just released is the very beginning of the project: it has basic functionality, but lacks many things, such as error handling and full support for the protocol. The documentation also needs a lot more work.

Example

I tried keeping the API very simple, and close to what an ORM would be used like, here’s an example:

import caldav
from caldav.lib.namespace import ns

# Principal url
url = "https://user:pass@hostname/user/Calendar"
vcal = """BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Example Corp.//CalDAV Client//EN
BEGIN:VEVENT
UID:1234567890
DTSTAMP:20100510T182145Z
DTSTART:20100512T170000Z
DTEND:20100512T180000Z
SUMMARY:This is an event
END:VEVENT
END:VCALENDAR
"""

client = caldav.DAVClient(url)
principal = caldav.Principal(url)
calendars = principal.calendars()
if len(calendars) > 0:
    calendar = calendars[0]
    print "Using calendar", calendar

    print "Renaming"
    calendar.set_properties({ns("D", "displayname"): "Test calendar",})
    print calendar.get_properties([ns("D", "displayname"),])

    event = caldav.Event(client, data = vcal, parent = calendar).save()
    print "Event", event, "created"

    print "Looking for events after 2010-05-01"
    results = calendar.date_search("20100501T000000Z")
    for event in results:
        print "Found", event

Links

I released caldav and its documentation on pypi, and the code is on bitbucket:

• Pypi: http://pypi.python.org/pypi/caldav
• Documentation: http://packages.python.org/caldav
• Bitbucket: http://bitbucket.org/cyrilrbt/caldav

Contributions are welcome!

• That there was some kind of RT function with rss feeds (the only feature I like about twitter)
• That Django Debug Toolbar is merged in django 1.2+

via Planet GNOME

BTW, I can’t believe no one else on Planet Django mentioned it yet!

That was working just fine, until I tried adding some of my users’ local accounts in different groups. The distant usernames follow the format <first_name>.<last_name>, and since Django doesn’t allow that, everytime I would try to save the user edit form in the admin interface, I would get an error message saying that the username format was invalid.

After looking around a bit, I found this solution, which has been working great for me.

from django.contrib.auth.forms import UserCreationForm, UserChangeForm
from django.contrib.auth.models import User
from django.contrib.auth.admin import UserAdmin
from django import forms
from django.utils.translation import ugettext_lazy as _
from django.contrib import admin

class UserCreationForm(UserCreationForm):
    username = forms.RegexField(label=_("Username"), max_length=30,
            regex=r"^[\w'\.\-]+\s?[\w'\.\-]+$")

class UserChangeForm(UserChangeForm):
    username = forms.RegexField(label=_("Username"), max_length=30,
            regex=r"^[\w'\.\-]+\s?[\w'\.\-]+$")

class UserProfileAdmin(UserAdmin):
    form = UserChangeForm
    add_form = UserCreationForm

admin.site.unregister(User)
admin.site.register(User, UserProfileAdmin)

OK, this article is a bit late, but I think it’s still necessary to properly introduce a new project.

At work last week, I had to write a generic way of exporting a QuerySet to csv, ods, and maybe some other format later on. Since I work at AUF, I frenched up the project’s name.

Why start from scratch?

I’m pretty sure that there already are a few apps that do that, but since I still consider myself kind of new to django, I thought it would be a good learning exercise to write this app myself.

The idea

The files I had to generate needed to have a header that described each column, and the values needed to be clear (no ids, etc.)

I decided to add a method to get the object’s fields (attribute name as well as verbose name), and another one to get the attributes’ values. That’s pretty much it for the Django part.

The last part of the project was to define a generic-enough method to export those fields in the file format we want. The file format is passed as a parameter so that it can be passed directly from the url.

Have a look

The code is now published on code.google.com. Feedback is always welcome.

While working on a rewrite of one of our web app here at AUF, I needed to replicate a logging functionality.

The old system was written with php4 (please don’t barf on your screen), and so you can imagine how such a thing could have been done:

1. Get current entry in the table.
2. Generate an insert query to save that version of the entry in the history table.
3. Perform the update on the main table.

Being lazy, as all programmers are, I looked around for an existing django app to do that, and I found django-history-tables, which does exactly what I need!

Long story short, the latest release was for django 0.96, which is pretty old, and so I had to modify it a bit to make it work on 1.1.1, and later on, I found out that it was really unstable on slightly complex models. Please note that this is by no means criticism towards django-history-tables’ author. I failed at fixing it.

So, what happens next? When the only solution I have fails, I have to buid one! Yay!

The concept

I figured the easiest way to this would require a couple of things:

• The model for the history table must be created by a syncdb
• It must be relatively easy to use

I decided then to start writing an abstract History, whose only job is to define a generic-enough saving method.

Here’s what it looks like

#!/usr/bin/env python
# -*- coding: utf-8 -*-
from django.db import models
from django.db.models.base import ModelBase
from django.db import connection, transaction
from copy import deepcopy
from datetime import datetime

class History (models.Model):
    history_datetime = models.DateTimeField(default=datetime.now)
    history_objectid = models.PositiveIntegerField()
    history_revision = models.PositiveIntegerField()
    history_comment = models.CharField(max_length=1024, default="")

    def save_log (self, instance):
        iClass = instance.__class__
        hClass = self.__class__

        # Reload the instance from db
        instance = iClass.objects.get(id = instance.id)
        self.history_objectid = instance.id
        self.history_comment = "pre_save history item <%s>" \
                % (repr(instance))
        self.history_revision = \
            hClass.objects.filter(history_objectid=instance.id).count()+1

        for field in instance._meta.fields:
            if field.__class__.__name__ != 'AutoField':
                if getattr(field, 'unique', False):
                    field._unique = False
                setattr(self, field.name, getattr(instance, field.name))

        super (History, self).save ()

    def save (self):
        pass

    class Meta:
        abstract = True

This class is pretty straightforward, the only odd thing is with the save method. I had to do this little hack because the rows in the history table would end up duplicated.

Usage

I think the best way to explain usage is by showing an example:

from django.db import models
from django_historique import History
from django.db.models.signals import pre_save, pre_delete

class Brand (models.Model):
    nom = models.CharField (max_length = 32)

    def __unicode__ (self):
        return "<Brand %s>" % self.nom

class CarBase (models.Model):
    marque = models.ForeignKey (Brand)
    couleur = models.CharField (max_length = 32)

    class Meta:
        abstract = True

class CarHistory (History, CarBase):
    def __unicode__ (self):
        return "<CarH %s, rev. %s>" \
                % (self.history_objectid, self.history_revision)

class Car (CarBase):
    id = models.AutoField (primary_key = True)
    def __unicode__ (self):
        return "<Car %s>" % self.id

def carhistory_save (sender, instance, signal, *args, **kwargs):
    history = CarHistory ()
    history.save_log (instance)
pre_save.connect(carhistory_save, sender=Car)
pre_delete.connect(carhistory_save, sender=Car)

A few comments:

• I do need to define an abstract CarBase that doesn’t include the id first, otherwise, django’s ORM screams that it’s not unique in the aggregate CarHistory class.
• The pre_save and pre_delete are what django offers us to execute actions before saving and deleting instances.

Issues

I can save ForeignKey values, so you will need to add a *History class for your foreign items and work some kind of time-based logic to figure out which version of the foreign object your instance was referring to

I don’t support ManyToMany fields

I hope you enjoyed it, the source code will be published on monday at google code: django-historique