brack3t

Not Exactly Tim the Enchanter

2012-11-06T10:30:51Z

Django has always been hailed as having great, awesome documentation. And, for the most part, this distinction has been deserved. But every once in a while, you find an area that's just...lacking. An area that you know exists but you've never gone into because it didn't come up and no one else used it but then you finally got a reason to use it...and then you find out it's so lacking in documentation that you have to dive into the source code.

This is one of those areas. Welcome to Django Form Wizard.

What is Django Form Wizard?

At it's most basic, Django's Form Wizard (DFW from now on, OK?) is a way to auto-generate a set of views w/ a single form in each view. Most of the time it uses one template but you can have a different template for each view. Most wizards have numbered steps but you can have named ones if you want. Also, most wizards deal with standard forms (highly recommended) but can, of course, use formsets and model forms.

You've all used wizards before, I'm sure. A set of forms that you fill out in order and, at the end, something larger is assembled from the information you provided. Usually it's an account or the install of a program or something of the like. I needed to produce a new product in an online store.

You Got Your Chocolate In My Peanut Butter

One thing I hate is putting logic where it doesn't belong. This is why you'll always see me importing my views classes (and creating view classes to begin with) into urls.py, even for views that go direct to template. As far as I'm concerned, urls.py is meant to be a mapping of regular expressions and nothing more.

DFWs don't let me have that separation of concerns, though (at least not in my experiences). I ended up having to import views, formset_factory and forms into urls.py and build out a couple of objects in the file. The messiness eats away at my CDO (OCD but in alphabetical order like it should be) even now, a week later. If this, alone, could be fixed, I'd be a much happier person. I should be able to provide a get_forms_list() method or forms_list class-level variable on the wizard view. Same goes for specifying the url_name, but I'm getting ahead of myself.

The View, Part One

For an area with very little documentation, there are quite a few WizardView sub-classes to pick from. The two most people will likely use are SessionWizardView or CookieWizardView, both of which work the same way but store the user's progress in a different place. The former obviously stores it in their session, the latter in a cookie on their machine. There are also named variants of both, NamedUrlSessionWizardView and NamedUrlCookieWizardView. I used the NamedUrlSessionWizardView because I wanted named steps in the URL (just looks nicer) and I wanted it stored in the user's session.

from django.contrib.formtools.wizard.views import NamedUrlSessionWizardView
from django.core.files.storage import FileSystemStorage

class ProductWizardView(LoginRequiredMixin, NamedUrlSessionWizardView):
    file_storage = FileSystemStorage()
    template_name = "seller/wizard_form.html"

Notice that I specify a file storage instance. If you don't specify this, and you need to support FileField or ImageField in your forms, you'll get errors from Django. This is something else I think could be handled by the views better. Seems to me that it should just use whatever the default/specified storage is for the rest of your project/application.

URLs

Now we jump to urls.py.

from django.forms.formsets import formset_factory

from app.forms import ProductModelForm, ShippingForm, PhotoForm
from app.views import ProductWizardView

shipping_formset = formset_factory(ShippingForm, max_num=25, extra=5)
photo_formset = formset_factory(PhotoForm, max_num=25, extra=5)

named_product_forms = (
    ("product", ProductModelForm),
    ("shipping", shipping_formset),
    ("photos", photo_formset)
)

product_wizard = ProductWizardView.as_view(named_product_forms,
    url_name="product_wizard_step")

urlpatterns = patterns('',
    url(r"^productwizard/(?P<step>[-\w]+)/$", product_wizard,
        name="product_wizard_step"),
    url(r"^productwizard/$", product_wizard, name="product_wizard"),
)

You can see what I mean about how messy urls.py has quickly become.

First, we import our forms and the view we stubbed out. Since I need multiple forms for building out shipping options and product photos, I spin up a couple of formset factories. For the record, I hate this implementation, too, if anyone wants to tackle a better invocation.

The tuple of two-tuples that is named_product_forms is where a bit of the magic happens. The first item in each tuple is the name of the step. This'll show up in your URL and you'll string-match this if you need to do special work on any given step (more on this in a minute). You pass this list of forms into your views as_view() method when you instantiate the view, along with a name for the step url version of your wizard view.

In your urlpatterns, you'll define two URLs for the one view, one that has a variable for the step and one that doesn't. These can probably be combined but, in my experiments, DFWs aren't really friendly to you being too clever.

View, Part Two

All DFWs have a method named done() that takes one explicit arg, form_list, and then any kwargs you want to pass into it. This step is run when all of your forms have been submitted and they've all passed validation. Here is an approximation of my view's done() method.

def done(self, form_list, **kwargs):
    product_form = form_list[0]
    shipping_forms = form_list[1]
    image_forms = form_list[2]

    productext = self.create_product(product_form)
    shippings = self.create_shippings(productext, shipping_forms)
    images = self.create_images(productext, image_forms)

    if all([productext, shippings, images]):
        del self.request.session["wizard_product_wizard_view"]

        messages.success(self.request,
            _("Your product has been created."))
        return HttpResponseRedirect(self.get_success_url(productext))

    messages.error(self.request, _("Something went wrong creating your "
        "product. Please try again or contact support."))
    return HttpResponseRedirect(reverse("product_wizard"))

The first thing I do is assign my forms to different variables for ease of reach. I have a few methods on my class for creating each of my model types. Each of these methods returns either True or False, which makes my call to any() the absolute easiest way to make sure they're all successful. If they are, I dump the wizard's variable from the session, set a message, and redirect (as you should always do after a POST). If not, I set another message and redirect back to the wizard view. This'll send the user to the last step of the form, just in case something else has come up. If, somehow, the user got to the done() step before completing the entire wizard, they'd be redirected to the last step they completed.

The session variable is created by Django by appending, with underscores, an un-camel-cased version of your class name to the word "wizard". This isn't specified in the docs anywhere, but you can see the build up of it here in Github. I found it just by examining the request.session object in a PDB shell.

One other method I overrode on the view is get_form_kwargs.

def get_form_kwargs(self, step):
    if step == "product":
        return {"user": self.request.user}
    return {}

Each step calls this method with either its index value or its name, depending on the type of DFW you're using. As you can see, I check to see if it's the product step and, if so, I return a dict with a user variable set to the current request's user.

Forms And The Template

I haven't shown any forms because they're not really special. I recommend you stick with non-ModelForm forms, though. Using ModelForm forms seems like a great idea until you remember that no forms are really processed, other than making sure they pass is_valid(), until the done() step. That means that if you have a ModelForm on steps one and two and the form on step two relies on the model instance created by the form in step one, step two's form will never be valid.

The template, also, isn't really special, in and of itself. In my implementation, though, I used django-crispy-forms and that presented a small problem to my normal flow.

Usually, in templates, I do something like the following to render a form:

{% load crispy_forms_tags %}
{% crispy form %}

That'll work great with DFWs with one small change in your form's helper.

class WizardForm(forms.Form):
    [...]

    def __init__(self, *args, **kwargs):
        self.helper = FormHelper()
        self.helper.form_tag = False
        [...]

I had to tell my forms not to render the form tag since I needed to be able to override the enctype on the tag. I also left off any submit buttons since you can add "Previous" and "First" buttons to the forms too.

Conclusion

Hopefully this gives you a pretty good idea of how to implement DFWs in your own product. They're a fairly useful way to create new items or lead a user through a lengthy form or process. Sadly it's not really useful for editing since it's difficult to pass in instances in the appropriate places. I'd love to see the docs expanded on this, both with actual documentation and with better examples.

AJAX and Django Views

2012-06-26T18:15:15Z

It seems that cleanly and easily doing AJAX views in Django is an area that gives a lot of people trouble. We like to do views as straight HTTP if at all possible, but there are always interactions that would be better served by not having a page load. We're also big fans of django-tastypie but it's a whole other ball of wax on its own, especially if you want to have views that write to the database. So, for the purposes of getting everyone up to speed doing AJAX with Django, we'll ignore Tastypie for now and just stick with ordinary views.

Django automatic CSRF

To start things off, put this bit of Javascript from the Django docs into a script that's loaded on all the pages where you'll be needing to perform AJAX views. This allows you to ignore the CSRF token for AJAX views, but it will be added as a request header.

We previously said this could be seen as a security loophole and that same-origin came into effect. Both of these statements are wrong.

AJAX & Form Field Errors

Before we get to the Django side, there are a few small scripts that we recycle on every project.

function apply_form_field_error(fieldname, error) {
    var input = $("#id_" + fieldname),
        container = $("#div_id_" + fieldname),
        error_msg = $("<span />").addClass("help-inline ajax-error").text(error[0]);

    container.addClass("error");
    error_msg.insertAfter(input);
}

function clear_form_field_errors(form) {
    $(".ajax-error", $(form)).remove();
    $(".error", $(form)).removeClass("error");
}

These two functions are pretty self-explanatory, but I'll go over them anyway. The first, apply_form_field_error, takes a field name and an error, finds the field on the page and sets the error text to the passed-in error. Our selectors here take advantage of how Twitter Bootstrap renders forms, so you may need to change the selectors to match your own markup. The second, clear_form_field_errors, removes the above text and classes, basicaly resetting the form. It's important to run this script before every AJAX submission so you don't get doubled-up errors if someone submits invalid data on the same field twice. You could add it to jQuery's beforeSend if you don't want to have to think about it.

There are a couple more useful utility functions that we thought might be useful for some people.

function django_message(msg, level) {
    var levels = {
        warning: 'alert',
        error: 'error',
        success: 'success',
        info: 'info'
    },
    source = $('#message_template').html(),
    template = Handlebars.compile(source),
    context = {
        'tags': levels[level],
        'message': msg
    },
    html = template(context);

    $("#message_area").append(html);
}

function django_block_message(msg, level) {
    var source = $("#message_block_template").html(),
        template = Handlebars.compile(source),
        context = {level: level, body: msg},
        html = template(context);

    $("#message_area").append(html);
}

These two scripts mirror Django's messages app's functionality. Both use Handlebars to render the template, but you could use any Javascript templating library you'd like. Our templates look like so:

{% load verbatim_tag %}
<script id="message_template" type="text/x-handlebars-template">
    {% verbatim %}
    <div class="alert alert-{{tags}} fade in" data-alert="{{tags}}">
        <a class="close" title="Close" href="#" data-dismiss="alert">&times;</a>
        {{{message}}}
    </div>
    {% endverbatim%}
</script>

<script id="message_block_template" type="text/x-handlebars-template">
    {% verbatim %}
    <div class="alert alert-block alert-{{level}} fade in">
        <a class="close" title="Close" href="#" data-dismiss="alert">&times;</a>
        {{{body}}}
    </div>
    {% endverbatim %}
</script>

The verbatim tag there is from Eric Florenzano and makes including Javascript templates in your Django-parsed HTML really easy. We include these in a base template and provide a spot in the rest of the document to attach them to. Again, this is based largely on Twitter Bootstrap, so your markup will vary.

AJAX Views

So now let's get down to the good stuff. The following view is very generic and only shows the basic concept, but we're sure you'll get the gist of it.

from django.http import HttpResponse, HttpResponseBadRequest
from django.utils import simplejson as json
from django.views.generic import UpdateView

from braces.views import LoginRequiredMixin, PermissionRequiredMixin

class PonyAjaxUpdateView(LoginRequiredMixin, PermissionRequiredMixin, UpdateView):

    form_class = PonyForm
    model = Pony
    permission_required = "ponies.change_pony"

    def form_valid(self, form):
        """
        If the request is ajax, save the form and return a json response.
        Otherwise return super as expected.
        """
        if self.request.is_ajax():
            self.object = form.save()
            return HttpResponse(json.dumps("success"),
                mimetype="application/json")
        return super(PonyAjaxUpdateView, self).form_valid(form)

    def form_invalid(self, form):
        """
        We haz errors in the form. If ajax, return them as json.
        Otherwise, proceed as normal.
        """
        if self.request.is_ajax():
            return HttpResponseBadRequest(json.dumps(form.errors),
                mimetype="application/json")
        return super(PonyAjaxUpdateView, self).form_invalid(form)

Again, nothing special in the view. We use an UpdateView so we can, technically, still use the view without AJAX. Assuming that the POST data that comes in validates on the form, our form_valid method will fire, which checks to see if the request was made via AJAX and, if so, returns a success string. Quite often we like to return a serialized version of the object that was just created or updated, but that takes some special considerations when it comes to Django model objects. If you don't need the object back, returning a standard HttpResponse or one with a message, like demonstrated above, is enough. When returning JSON, make sure to include the mimetype="application/json" in your HttpResponse. Without the proper mimetype you will be dealing with text/html content instead of JSON. If your view creates new objects or deletes old ones, returning proper status codes, like 201 for Created is a very polite thing to do, especially if you think your view will end up as part of an ad hoc API.

Similarly, above, if the form is invalid, we serialize the form errors (note: not the non_field_errors() errors) and send them back to the view. The script we wrote above, apply_form_field_error can be called in a loop for each error in the list and update your form so the users know what they did wrong.

note Did you notice the braces package we used in the above view? That's a package we released from a previous blog post on custom class-based view mixins. You can get it on Github or PyPI.

Form Errors

The difference between form.errors and form.non_field_errors(): form.errors are any errors directly related to a field in your form, form.non_field_errors() would include errors raised by a custom clean() method and are put into a special "field" called __all__.

The jQuery Side

HTML

<form id="pony_form" method="POST" action="{% url pony_update_view pony.pk %}">
    {% csrf_token %}
    <label for="id_name">Pony Name</label>
    <input type="text" name="name" id="id_name">
    <input type="submit" value="Submit">
</form>

This isn't anything special, as you can see. Just a standard HTML form, like would be rendered by Django's form template filters (e.g. {{ form|as_ul }}). If you need to perform AJAX tasks on non-form elemnts, the HTML5-added data- attribute is really handy. We use it a lot for holding on to URLs and primary keys like: <li data-url="{% url pony_update_view pony.pk %}" data-pk="{{ pony.pk }}">{{ pony.name }}</li>. This is useful for sortable interfaces, for example.

jQuery

$(document).on("submit", "#pony_form", function(e) {
    e.preventDefault();
    var self = $(this),
        url = self.attr("action"),
        ajax_req = $.ajax({
            url: url,
            type: "POST",
            data: {
                name: self.find("#id_name").val()
            },
            success: function(data, textStatus, jqXHR) {
                django_message("Pony saved successfully.", "success");
            },
            error: functior(data, textStatus, jqXHR) {
                var errors = $.parseJSON(data.responseText);
                $.each(errors, function(index, value) {
                    if (index === "__all__") {
                        django_message(value[0], "error");
                    } else {
                        apply_form_field_error(index, value);
                    }
                });
            }
        });
});

Again, nothing special if you're used to doing AJAX requests in jQuery. We stop the form from actually submitting using preventDefault() on the submission event, then build a few variables. Luckily we can get the URL directly off the form; this is part of why we end up using the data- attributes a lot, so we can separate our templates from our Javascript. We typically go through and name out the keys that we want to send through to the backend view in the data dict, but you could use serialization options provided by jQuery or another plugin. These just seem to have a lot of quirks that we'd rather not take into consideration (especially not for an example in a blog post). Our way is definitely more manual but less error-prone.

We then provide success and error attributes for the .ajax() call. These can be provided outside of the .ajax() call, which is very useful if your code is more modular, but we rarely have need of that approach. The success function just prints out a message to the user, letting them know everything saved correctly. This is where you would update UI elements or whatever your use case requires.

The error function turns the JSON string that our view returned into a Javascript object so we can dig through it more easily (no one likes to parse text). We loop through all of the provided errors and, depending on if their key indicates them to be global or field-specific, render them out to the page for the user. Again, this is where you'd want to update your interface.

Summary

To be honest, we don't end up using AJAX in exactly the method prescribed above. We usually use AJAX for utilitarian functions, like saving the order of records, activating/deactivating records, and deleting records in many-to-many joining tables. That said, our utilization of AJAX and the one above are 99% identical, so don't feel that we're giving you advice we wouldn't stand behind.

The ability to update, delete, and reorder elements without requiring a page load really adds a lot to your interface (assuming it's appropriate) and doing that with Django is amazingly easy. We've heard a few people say that class-based views make AJAX harder, or at least that it's easier with function-based views, but we haven't seen that to be the case at all. So don't be afraid to try AJAX regardless of the type of view you prefer.

Notes

If you're doing a lot of AJAX work, look into an API framework like django-tastypie or django-rest-framework. We hope to cover more on Tastypie in a later post. These two frameworks become even more useful when you delve into things like Backbone.js.
We don't recommend doing create, update, or delete of first-class records through AJAX. We both feel that the response of a new page load gives some finality and completeness to the process that users expect, which is why the above example isn't based directly off code we've written for any clients. If you disagree, feel free to use the above examples to create your user experience. If you agree, we're sure you can modify the above code, as we do, to handle sort ordering, joining/disjoining, and other second-class record manipulation.
We felt like the above UpdateView was a fairly solid and well-rounded example. If you need more information or examples, let us know in the comments and we'll gladly extend the post.

Generic Layouts in Crispy Forms

2012-06-26T18:15:15Z

Just a quick tip and sanity check, today, about something I ran into with django-crispy-forms, the awesome new form library from Miguel Araujo.

This morning, I converted the project we've been building for a client (currently some 1,700 or so files, counting templates, CSS, and icons) from django-uni-form to django-crispy-forms. It's a pretty painless transition, actually. Just do some find-and-replace across your files, basically changing any instance of uni- to crispy- (well, and form to forms), and you're good to go. Then, however, I wanted to convert two large forms that we have, which share 90% of their fields, to using the sharable Layout objects that django-crispy-forms gives us.

Basically, the forms looked like this:

class FirstForm(GenericAppFormForTheExample):
    ...

    def __init__(self, *args, **kwargs):
        ...
        self.helper = FormHelper()
        self.helper.layout = Layout(
            "field1",
            "field2",
            "special-field",
            [field3 through field20]

class SecondForm(GenericAppFormForTheExample):
    ...

    def __init__(self, *args, **kwargs):
        ...
        self.helper = FormHelper()
        self.helper.layout = Layout(
            "field1",
            "field2",
            "special-field2",
            [field3 thorugh field20]

Obviously that was a lot of repetition that we could cut out now that these inheritable layouts exist. By the way, I'm pretty sure this would have been possible in django-uni-form but likely not as friendly.

First I started off by creating the shared resources. I made two of them since our special fields come in the middle of our layouts.

form_intro_layout = Layout(
    "field1",
    "field2"
)

form_common_layout = Layout(
    [field3 through field20]
)

And I added them each into my forms. I'm only going to show one form but you'll get the idea.

self.form_intro_layout = form_intro_layout
self.form_intro_layout.insert(-1, "special-field")

self.helper.layout = Layout(
    self.form_intro_layout,
    form_common_layout
)

And, display-wise, it worked fine. This is, ideally, exactly what you do to extend these layouts. But, this causes problems in testing.

We test all of our views, models, and forms. The form tests passed fine, but some of the view tests were throwing up warnings about fields being referenced more than once and, for example, special-field2 missing from FirstForm. Obviously something was up with the inheritance and with how I was instantiating objects.

My next step was to stop using self on the instance-specific versions of the generic layouts and just give them a local name like standard_intro_layout (the standard name makes more sense internally and its meaning isn't important for this example), but that didn't stop the errors. It did, however, still work fine visually.

I tried using a .copy() method on the layout, but that doesn't exist. So I turned to the copy module of Python, specifically the deepcopy method. I tried with just the standard copy method, but it had the same effect of working visually, but throwing warnings on tests.

The new version looked like this:

from copy import deepcopy

standard_intro_layout = deepcopy(form_intro_layout)
standard_intro_layout.insert(-1, "special-field")
...

That works perfectly! It still appears the same visually, like all the methods have, and it also quiets the tests so they pass without warnings.

Unless someone knows of a reason I shouldn't use deepcopy, this seems to be the way to solve this problem. I'm also not sure if it was the self (which I doubt, since I removed it and the warnings still happened), or the fact that both forms extend the same abstract form, or some other variable that led to the problem. Regardless, I'm happy to have solved it.

Our Custom Mixins

2012-06-26T18:15:15Z

UPDATE: We've released a Github repo and a PyPI package with our mixins. Feel free to fork and submit new ones through a pull-request.

Let's just start out and say it, Class Based Views. Ooohhhh. Unfortunately the topic of class based views is thought of as somewhat of a dark art in the Django community. It doesn't help that the documentation is still lacking but I find a lot of people, especially on Reddit, refuse to use them. For whatever reason, it's a hard pill for some to swallow.

Before DjangoCon 2011, we started playing with class-based views. At first they seemed like a nightmare and without decent docs, we got frustrated really quickly. Skip forward to today and I can't imagine writing old function-based views again. Some argue that the generic views are only for generic applications and that, somehow, their work is far too custom and complex to be handled in a generic class-based view. Based on my experience, 99% of the time, they would be wrong.

We plan on covering generic class-based views extensively with GSWD. Today, I'd like to share some mixins we have cooked up, on a rather large client project, that have helped us out tremendously.

For those of you not familiar with decorating class-based views, check out the Django documentation on decorating the class. We don't like the idea of doing decoration in Django's urls.py or creating another instance variable just to hold a decorated class. To us, mixins feel more Pythonic.

Mixins

LoginRequiredMixin
PermissionRequiredMixin
SuperuserRequiredMixin
UserFormKwargsMixin
UserKwargModelFormMixin
SuccessURLRedirectListMixin
SetHeadlineMixin
Conclusion

LoginRequiredMixin

class LoginRequiredMixin(object):
    """
    View mixin which verifies that the user has authenticated.

    NOTE:
        This should be the left-most mixin of a view.
    """

    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        return super(LoginRequiredMixin, self).dispatch(*args, **kwargs)

This mixin is rather simple and is generally the first inherited class in any of our views. If we don't have an authenticated user there's no need to go any further. If you've used Django before you are probably familiar with the login_required decorator. All we are doing here is requiring a user to be authenticated to be able to get to this view.

While this doesn't look like much, it frees us up from having to manually overload the dispatch method on every single view that requires a user to be authenticated. If that's all that is needed on this view, we just saved 3 lines of code. Example usage below.

from django.views.generic import TemplateView

from myapp.mixins import LoginRequiredMixin


class SomeSecretView(LoginRequiredMixin, TemplateView):
    template_name = "path/to/template.html"

    def get(self, request):
        return self.render_to_response({})

PermissionRequiredMixin

class PermissionRequiredMixin(object):
    """
    View mixin which verifies that the logged in user has the specified
    permission.

    Class Settings
    `permission_required` - the permission to check for.
    `login_url` - the login url of site
    `redirect_field_name` - defaults to "next"
    `raise_exception` - defaults to False - raise 403 if set to True

    Example Usage

        class SomeView(PermissionRequiredMixin, ListView):
            ...
            # required
            permission_required = "app.permission"

            # optional
            login_url = "/signup/"
            redirect_field_name = "hollaback"
            raise_exception = True
            ...
    """
    login_url = settings.LOGIN_URL
    permission_required = None
    raise_exception = False
    redirect_field_name = REDIRECT_FIELD_NAME

    def dispatch(self, request, *args, **kwargs):
        # Verify class settings
        if self.permission_required == None or len(
            self.permission_required.split(".")) != 2:
            raise ImproperlyConfigured("'PermissionRequiredMixin' requires "
                "'permission_required' attribute to be set.")

        has_permission = request.user.has_perm(self.permission_required)

        if not has_permission:
            if self.raise_exception:
                return HttpResponseForbidden()
            else:
                path = urlquote(request.get_full_path())
                tup = self.login_url, self.redirect_field_name, path
                return HttpResponseRedirect("%s?%s=%s" % tup)

        return super(PermissionRequiredMixin, self).dispatch(
            request, *args, **kwargs)

This mixin was originally written, I believe, by Daniel Sokolowski (code here).

The permission required mixin has been very handy for our client's custom CMS. Again, rather than overloading the dispatch method manually on every view that needs to check for the existence of a permission, we inherit this class and set the permission_required class attribute on our view. If you don't specify permission_required on your view, an ImproperlyConfigured exception is raised reminding you that you haven't set it.

The one limitation of this mixin is that it can only accept a single permission. It would need to be modified to handle more than one. We haven't needed that yet, so this has worked out well for us.

In our normal use case for this mixin, LoginRequiredMixin comes first, then the PermissionRequiredMixin. If we don't have an authenticated user, there is no sense in checking for any permissions.

note If you are using Django's built in auth system, superusers automatically have all permissions in your system.

SuperuserRequiredMixin

class SuperuserRequiredMixin(object):
    login_url = settings.LOGIN_URL
    raise_exception = False
    redirect_field_name = REDIRECT_FIELD_NAME

    def dispatch(self, request, *args, **kwargs):
        if not request.user.is_superuser:
            if self.raise_exception:
                return HttpResponseForbidden()
            else:
                path = urlquote(request.get_full_path())
                tup = self.login_url, self.redirect_field_name, path
                return HttpResponseRedirect("%s?%s=%s" % tup)

        return super(SuperuserRequiredMixin, self).dispatch(
            request, *args, **kwargs)

Another permission-based mixin. This is specifically for requiring a user to be a superuser. Comes in handy for tools that only privileged users should have access to.

UserFormKwargsMixin

class UserFormKwargsMixin(object):
    """
    CBV mixin which puts the user from the request into the form kwargs.
    Note: Using this mixin requires you to pop the `user` kwarg
    out of the dict in the super of your form's `__init__`.
    """
    def get_form_kwargs(self, **kwargs):
        kwargs = super(UserFormKwargsMixin, self).get_form_kwargs(**kwargs)
        kwargs.update({"user": self.request.user})
        return kwargs

In our clients CMS, we have a lot of form-based views that require a user to be passed in for permission-based form tools. For example, only superusers can delete or disable certain objects. To custom tailor the form for users, we have to pass that user instance into the form and based on their permission level, change certain fields or add specific options within the forms __init__ method.

This mixin automates the process of overloading the get_form_kwargs (this method is available in any generic view which handles a form) method and stuffs the user instance into the form kwargs. We can then pop the user off in the form and do with it what we need. Always remember to pop the user from the kwargs before calling super on your form, otherwise the form gets an unexpected keyword argument and everything blows up. Example usage:

from django.views.generic import CreateView

from myapp.mixins import LoginRequiredMixin, UserFormKwargsMixin
from next.example import UserForm


class SomeSecretView(LoginRequiredMixin, UserFormKwargsMixin,
    TemplateView):

    form_class = UserForm
    model = User
    template_name = "path/to/template.html"

UserKwargModelFormMixin

class UserKwargModelFormMixin(object):
    """
    Generic model form mixin for popping user out of the kwargs and
    attaching it to the instance.

    This mixin must precede forms.ModelForm/forms.Form. The form is not
    expecting these kwargs to be passed in, so they must be poppped off before
    anything else is done.
    """
    def __init__(self, *args, **kwargs):
        self.user = kwargs.pop("user", None)
        super(UserKwargModelFormMixin, self).__init__(*args, **kwargs)

The UserKwargModelFormMixin is a new form mixin we just implemented this week to go along with our UserFormKwargsMixin. This becomes the first inherited class of our forms that receive the user keyword argument. With this mixin, we have automated the popping off of the keyword argument in our form and no longer have to do it manually on every form that works this way. While this may be overkill for a weekend project, for us, it speeds up adding new features. Example usage:

class UserForm(UserKwargModelFormMixin, forms.ModelForm):
    class Meta:
        model = User

    def __init__(self, *args, **kwargs):
        super(UserForm, self).__init__(*args, **kwargs):

        if not self.user.is_superuser:
            del self.fields["group"]

SuccessURLRedirectListMixin

class SuccessURLRedirectListMixin(object):
    """
    Simple CBV mixin which sets the success url to the list view of
    a given app. Set success_list_url as a class attribute of your
    CBV and don't worry about overloading the get_success_url.

    This is only to be used for redirecting to a list page. If you need
    to reverse the url with kwargs, this is not the mixin to use.
    """
    success_list_url = None

    def get_success_url(self):
        return reverse(self.success_list_url)

The SuccessURLRedirectListMixin is a bit more tailored to how we handle CRUD within our CMS. Our CMS's workflow, by design, redirects the user to the ListView for whatever model they are working with, whether they are creating a new instance, editing an existing one or deleting one. Rather than having to override get_success_url on every view, we simply use this mixin and pass it a reversible route name. Example:

# urls.py
url(r"^users/$", UserListView.as_view(), name="cms_users_list"),

# views.py
class UserCreateView(LoginRequiredMixin, PermissionRequiredMixin,
    SuccessURLRedirectListMixin, CreateView):

    form_class = UserForm
    model = User
    permission_required = "auth.add_user"
    success_list_url = "cms_users_list"
    ...

SetHeadlineMixin

class SetHeadlineMixin(object):
    """
    Mixin allows you to set a static headline through a static property on the
    class or programmatically by overloading the get_headline method.
    """
    headline = None

    def get_context_data(self, **kwargs):
        kwargs = super(SetHeadlineMixin, self).get_context_data(**kwargs)
        kwargs.update({"headline": self.get_headline()})
        return kwargs

    def get_headline(self):
        if self.headline is None:
            raise ImproperlyConfigured(u"%(cls)s is missing a headline. Define "
                u"%(cls)s.headline, or override "
                u"%(cls)s.get_headline()." % {"cls": self.__class__.__name__
            })
        return self.headline

The SetHeadlineMixin is a newer edition to our client's CMS. It allows us to statically or programmatically set the headline of any of our views. We like to write as few templates as possible, so a mixin like this helps us reuse generic templates. Its usage is amazingly straightforward and works much like Django's built-in get_queryset method. This mixin has two ways of being used.

Static Example

class HeadlineView(SetHeadlineMixin, TemplateView):
    headline = "This is our headline"
    template_name = "path/to/template.html"

Dynamic Example

from datetime import date


class HeadlineView(SetHeadlineMixin, TemplateView):
    template_name = "path/to/template.html"

    def get_headline(self):
        return u"This is our headline for %s" % date.today().isoformat()

In both usages, in the template, just print out {{ headline }} to show the generated headline.

Conclusion

Hopefully we've inspired you to use class-based views and custom mixins in your own projects or, at the very least, give class-based views another look. Writing custom mixins helps to alleviate pain points in your project and make it faster to create new features, at least is has for us. If you have any questions, leave a comment or hit us up on Twitter.

User-friendlier model forms

2012-06-26T18:15:15Z

Recently, in our large client project, we had need of fields, in a model form, that accepted multiple types of input, but sanitized the data for the model. For example, the rent field, on the form, needs to handle a rent range (e.g. 900-1200), a single amount, or be overridden or extended by other bits of information, like "call for details" or "on approved credit". Obviously we don't want to have to parse this out every time we read the data. So, enter our fields that tear data apart and put it together every time it passes through.

Model

Let's go over our Rent model first. It's an abstract model so we can use it in multiple places (we have more than one logical model in the system that needs to deal with rent, this way we can use it multiple places without having to hold on to a huge amount of joins). We have several other abstract models that perform the same actions as our Rent model, but I won't show them here.

from django.core.exceptions import ValidationError
from django.db import models


class Rent(models.Model):
    rent_low = models.PositiveIntegerField()
    rent_high = models.PositiveIntegerField(blank=True, null=True)
    rent_percent_income = models.FloatField(blank=True, null=True)
    rent_oac = models.BooleanField(default=False)
    rent_call_for_details = models.BooleanField(default=False)
    rent_up_to = models.PositiveIntegerField(blank=True, null=True)

    class Meta:
        abstract = True

    def clean(self):
        super(Rent, self).clean()
        if self.rent_high and self.rent_high <= self.rent_low:
            raise ValidationError("Invalid rent range.")

        if self.rent_percent_income or self.rent_call_for_details or \
           self.rent_up_to:

            self.rent_low = 0
            self.rent_high = None

    @property
    def rent(self):
        if self.rent_call_for_details:
            return u"Call for details."

        if self.rent_up_to:
            return u"Up to $%d" % self.rent_up_to

        response = ""

        if self.rent_percent_income:
            response += u"%g%% of income." % self.rent_percent_income

        if self.rent_high:
            response +=  u"%d-%d" % (self.rent_low, self.rent_high)

        if self.rent_low > 0 and not self.rent_high:
            response += u"%d" % self.rent_low

        if self.rent_oac:
            response += " On approved credit."

        return response

The one "gotcha" here, that you may not get right away, is the super(Rent, self).clean() at the top of the clean(). We explicitly call it here to make sure the cleaning continues up the chain in our models that extend Rent and the other extended models (as mentioned, we have several models created and used this way). You'll notice in the model we have a field for each of our states, the low and high values of rent, and the other fields that override the rent output value. We also have a class property of rent that we can call on the extending models to get the computed rent value.

That property doesn't do anything really interesting except return a value based on the field values. The clean is a little more interesting for how it sets rent_low to 0 and empties out rent_high when their values no longer matter.

Form

from django.core.validators import RegexValidator

[...]

integer_range = RegexValidator(
    regex=re.compile(r"^[0-9]*(-[0-9]*)?$"),
    message="Please enter a valid number, or a range in the format: 100-200",
    code="invalid"
)


class FloorplanBaseForm(CommunityKwargModelFormMixin, UserKwargModelFormMixin,
    forms.ModelForm):

    rent = forms.CharField(max_length=75, required=False,
        validators=[integer_range])

    class Meta:
        model = Floorplan


    def __init__(self, *args, **kwargs):
        super(FloorplanBaseForm, self).__init__(*args, **kwargs)

        [...]

        if self.instance.pk:
            set_custom_fields(self, ["rent", "deposit", "promo", "sq_ft"])

    def clean(self):
        super(FloorplanBaseForm, self).clean()
        data = self.cleaned_data

        [...]

        if data.get("rent", None) and not data["rent_call_for_details"] and not\
            data["rent_percent_income"] and not data["rent_up_to"]:

            split_ranges(self, "rent")

        clean_custom_fields(self, data, ["rent", "rent_call_for_details",
            "rent_up_to", "rent_percent_income"],
            "You must enter a value for rent.", "rent")

        return data

I've removed bits of the form that deal with other fields like rent since I'm not showing anything about them. This is, more or less, an abstract form. We never render it, but we extend it to support our specific floorplan types. In those extending forms, we tell rent_low and rent_high to be excluded. In this form, though, we provide a single rent field that has a regular expression validator on it to ensure that it contains an interger or two integers separated by a hyphen. This lets the users enter data as more-or-less natural text instead of having to tab through a bunch of fields or enter the data in a weird format.

You'll notice three custom methods being called, set_custom_fields, split_ranges, and clean_custom_fields. We'll cover them next.

Custom methods

Let's go over these one at a time.

def clean_custom_fields(form, cleaned_data, fields, error_msg, field):
    """
    Make sure at least one required option has been supplied.
    """
    if not any([cleaned_data.get(f, None) for f in fields]):
        form.errors[field] = form.error_class([error_msg])

Since we have more than one field to clean, but they can be used in several different combinations, we have to make sure that at least one of the fields is provided. The any method from the Python standard library is amazingly useful for this. We pass in the form, because, again, we use this multiple places, our form's cleaned data, the fields we want checked, an error message, and the field to highlight if none of them are provided. This is a fairly useful and flexible solution that has, so far, fulfilled all of our needs.

Next is the split_ranges field.

def split_ranges(form, field):
    """
    Split custom range fields into model fields.
    """
    try:
        low, high = form.cleaned_data[field].split("-")
        setattr(form.instance, field + "_low", int(low))
        setattr(form.instance, field + "_high", int(high))
    except ValueError:
        setattr(form.instance, field + "_low", int(form.cleaned_data[field]))
        setattr(form.instance, field + "_high", None)

This small little method takes our unified field in the form and splits it out into the high and low fields on the model. Since our fields are named reliably and similarly, we're able to set fields without knowing all the names.

Also, notice how we use the ValueError that'll be thrown by not having a high value to set on the form to trigger it being set to None, exactly what our model is expecting already.

def set_custom_fields(form, fields):
    """
    Combine low/high fields into the range fields.
    """
    for field in fields:
        if getattr(form.instance, field + "_high", None):
            form.fields[field].initial = u"%d-%d" % (
                getattr(form.instance, field + "_low")
                getattr(form.instance, field + "_high")
            )

        if getattr(form.instance, field + "_low", None) > 0 and not \
            getattr(form.instance, field + "_high", None):

            form.fields[field].initial = gettar(form.instance, field + "_low")

This method is the reverse of the one above. We look at the initial data that is passed in when editing a model instance and combine our values so they match what the user would have already entered.

So, that model and that form combined with those methods lets us handle natural language entries for somewhat complex data. Granted, our use case would be negated by adding an extra field, but it's less friendly. One of our biggest goals on any client work we do is to make it user-friendly and a solid user experience all the way around. This bit of extra work has helped us do that quickly and easily.

Hopefully this gives you some ideas on how to make forms more user-friendly while maintaining solid model data on the backend. If you see something we could be doing better, please let us know in the comments.

Thanks to Kevin Diale for pointing out our oversight on getattr/setattr.

Change Request Workflow

2012-02-26T11:01:00Z

Before we start, let me explain a bit about what the app we're covering here is. It's a geo-spatial database, basically, of Points of Interest (POIs) for housing communities that we developed for a client of ours (or, rather, are still developing). Users and editors can both enter Points into the database, which is PostgreSQL with PostGIS, and then they can be associated with any community. Obviosuly, though, that leads to the problem of Community A editing a POI and Community B showing that data without their knowledge, so we'd like to have an editor look at the changes first. That's the need that lead to our workflow.

Models

First, let's start with the models.

class POIAbstract(LumberjackModel, models.Model):
    category = models.ForeignKey(Category, related_name="%(class)s_points")
    name = models.CharField(max_length=255)
    address = models.CharField(max_length=255)
    address2 = models.CharField(max_length=255, blank=True)
    city = models.CharField(max_length=100)
    state = USPostalCodeField()
    zip_code = models.CharField(max_length=10)
    phone = PhoneNumberField(blank=True, default="")
    url = models.URLField(blank=True, default="")
    point = models.PointField(blank=True, null=True, editable=False)
    objects = models.GeoManager()

    class Meta:
        abstract = True

    def __unicode__(self):
        return self.name

    @property
    def coords(self):
        """
        Return tuple of lat,lng
        """
        if self.point:
            return (self.point.get_coords()[1], self.point.get_coords()[0])
        return (None, None)

    @property
    def full_address(self):
        """
        Return a string of the full address
        """
        addresses = [self.address, self.address2, self.city, self.state,
            self.zip_code, "USA"]
        return ", ".join(filter(lambda x: len(x) > 0, addresses))


class POI(POIAbstract):
    """
    Points of Interest model.
    """
    pass


class POIChange(POIAbstract):
    """
    Holds proposed changes to POIs
    """
    STATUS_CHOICES = (
        (0, "Pending"),
        (1, "Denied"),
        (2, "Approved")
    )

    poi = models.ForeignKey(POI, related_name="changes")
    user = models.ForeignKey(User, related_name="poi_changes")
    submitted_on = models.DateField(auto_now_add=True, editable=False)
    approved_by = models.ForeignKey(User, related_name="poi_approvals",
        blank=True, null=True, editable=False)
    approved_on = models.DateField(blank=True, null=True, editable=False)
    status = models.PositiveSmallIntegerField(choices=STATUS_CHOICES,
        default=0, editable=False)

    class Meta:
        ordering = ["status", "-submitted_on"]

As you can see, there's not really anything too interesting about the models. We have an abstract model that we inherit both of our other models from. The approved record model is just the abstract model without it's abstract = True setting. The change model, though, adds a few fields.

First we point to the record we're changing. Then we hold on to the user that submitted the changes, and the time of the request. We also want to have a record of who approved/denied it and when. And, of course, we need to know what the status of the change is. That'll let us change our minds later on.

Forms

We usually end up building forms after we build models (more on this when we finish GSWD), so let's look at them next.

class POIForm(forms.ModelForm):
    latitude = forms.FloatField(required=False,
        widget=forms.HiddenInput())
    longitude = forms.FloatField(required=False,
        widget=forms.HiddenInput())

    class Meta:
        model = POI


class POIChangeForm(forms.ModelForm):
    latitude = forms.FloatField(required=False,
        widget=forms.HiddenInput())
    longitude = forms.FloatField(required=False,
        widget=forms.HiddenInput())

    class Meta:
        model = POIChange
        widgets = {
            "poi": forms.HiddenInput(),
            "user": forms.HiddenInput()
        }

I've left out some of the boilerplate and Layout bits from django-uni-form (we haven't upgraded to django-crispy-forms yet) but you get the general idea. Honestly, we could have made the second form inherit from the first and saved a bit of typing/space, but I guess we missed that. Both forms, ultimately, show the same thing. The latter form, though, holds onto a few extra fields that we need and that we'll set in the view.

Speaking of views, let's check them out.

Views

We're not going to look at the view that creates the original POI. It's just a standard CreateView that specifies our POIForm as the form_class. We have a couple of handy mixins on the views that let us control permissions and redirects, but we'll talk about them in another blog post.

The view we do want to look at is our POIUpdateView which is the one that let's users submit changes for a particular POI. Now, this view is the one that's linked to for each record on the list page; we never link to a view where a user can directly update a POI, not even for editors/superusers. So, here's our POIUpdateView:

note We use a few mixins below that aren't part of the standard Django library: LoginRequiredMixin, PermissionRequiredMixin, SuccessURLRedirectListMixin, and SetHeadlineMixin.

class POIUpdateView(LoginRequiredMixin, PermissionRequiredMixin,
    SuccessURLRedirectListMixin, SetHeadlineMixin, CreateView):
    """
    View allows users to propose changes to current POIs.
    """

    form_class = POIChangeForm
    headline = "Edit point of interest"
    model = POIChange
    permission_required = "points.change_poi"
    success_list_url = "cms_points_list"
    template_name = "cms/points/poi_form_edit.html"

    def get_initial(self):
        """
        Do you believe in magic, in a young devs heart?
        How the code can free 'em whenever it starts,
        and it's magic, if the code is groovy.

        Use POI information for initial data in POIChangeForm.
        """
        poi = POI.objects.get(pk=self.kwargs["pk"])
        initial = poi.__dict__.copy()
        del initial["_state"]
        initial.update({
            "category": poi.category,
            "latitude": poi.point.get_coords()[1],
            "longitude": poi.point.get_coords()[0],
            "user": self.request.user,
            "poi": poi
        })
        return initial

    def post(self, request, pk, *args, **kwargs):
        response = super(POIUpdateView, self).post(request, pk, *args, **kwargs)

        url = settings.CMS_URL + reverse("cms_points_change_detail",
            kwargs={"pk": self.object.pk})
        message = render_to_string("cms/points/email/admin_email.html", {"user":
            self.object.user.get_full_name(), "url": url})
        mail_admins("POI Change Request", message)

        return response

I think how this view works is pretty cool. It's a fairly standard CreateView that points to our POIChange model. We don't just start with a blank POIChange, though. By overriding get_initial to load the POI with the PK that comes through in the URL, we can set the beginning data of the record. We fetch the instance, update our initial data with its values, and then pass it on through to the form.

Once the form is valid, a method I don't show above, called form_valid, is fired by Django as part of its form-based generic view workflow and then we log the change in our logger, send a message to the user through Django's messages app, and then our post method gets called. Learning the workflow order of CreateView and UpdateView (and, ultimately, FormView) will save you a huge amount of time when you start customizing these things. In our post method, we render out an email to the admins and then return our response, which, thanks to our SuccessURLRedirectListMixin will redirect the user to the route named in success_list_url.

Now, all we've really done is create a new record. It still has to be approved. We do that in our next view, POIChangeApprovalView, which the editor/superuser gets to through another list view. They can also reach it by clicking the link provided to them in the email.

class POIChangeApprovalView(LoginRequiredMixin, SuperuserRequiredMixin,
    DetailView):

    model = POIChange
    template_name = "cms/points/poi_change_detail.html"

    def post(self, request, pk):
        approval = request.POST.get("approval", None)
        if approval:
            if approval == "approve":
                self._approved()
            else:
                self._denied()
            return HttpResponseRedirect(reverse("cms_points_change_list"))

        return HttpResponseForbidden()

    def _approved(self):
        """
        It's approved!
        """
        poi = self.get_object()
        data = poi.__dict__.copy()
        del data["_state"]
        data.update({
            "category": poi.category.pk,
            "latitude": poi.coords[0],
            "longitude": poi.coords[1],
        })
        form = POIForm(data, instance=poi.poi)
        if form.is_valid():
            form.save()

            poi.status = 2
            poi.approved_by = self.request.user
            poi.approved_on = date.today()
            poi.save()

            messages.success(self.request, "Point of interest updated.")

            if poi.user.email:
                message = render_to_string("cms/points/email/approved.html",
                    {"poi_name": poi.name})
                send_mail("OUR CLIENT - Change Request Approved",
                    message, settings.EMAIL_HOST_USER, [poi.user.email])

    def _denied(self):
        """
        No way Jose
        """
        poi = self.get_object()
        poi.status = 1
        poi.approved_by = self.request.user
        poi.approved_on = date.today()
        poi.save()

        messages.success(self.request,
            "Point of interest '%s' has not been updated." % poi.poi.name)

        if poi.user.email:
            message = render_to_string("cms/points/email/denied.html",
                {"poi_name": poi.name})
            send_mail("OUR CLIENT - Change Request Denied",
                message, settings.EMAIL_HOST_USER, [poi.user.email])

This view is really straightfoward. The editor clicks one of two buttons, both of which point to this view. One contains a POST variable indicating approval, the other indicating that the change has been denied. Then, based on the value, we peform the same action on the POIChange.

If the change was denied, we just set the status on the change to our denied flag, set the date and user, and then save it.

If it was approved, we create an instance of the POIForm with the changed POI as the edited instance and our POIChange's __dict__ as the new data. Since they're copies of each other, aside from the changes in the change model, of course, only the changed data really gets updated. We make sure the form is still valid (some GeoDjango stuff I left out of the form above) and then save the updated instance. We also update the POIChange so it holds the new status, the approving user and date.

Regardless of the action taken, we send off an email to the user that submitted the change, letting him or her know what happened.

Summary

This has, so far, been a great workflow for our users. They're able to trust that the data going out is verified and safe, but if anything gets out of date, we can change it ourselves or let the community of users tell us about the new data.

There is a lot of stuff I didn't cover, what the Point field holds on to, how to actually use GeoDjango, what each of our custom mixins does (we're planning on releasing these as a package soon), and lots of other stuff. If you have questions/comments, hit us up on Twitter. Also, thanks to Daniel Greenfeld for a couple of edits.

Djangopeople.me

2011-06-13T18:50:00Z

What is it?

At it's core, djangopeople.me is a place for Django developers to register and be found based on their geographic location, whether it's by recruiters or a lonely Django developer like ourselves trying to find others close to him/her. That's the general idea behind the site.

We wanted to make it clean, simple and fast. For the maps we ended up using Leaflet's open-source Javascript library. We initially started with Google Maps, but the rate limiting was too restrictive on the geocoding API for our needs and frankly, loading maps seemed very slow. So, with the project being free-to-use (and us being cheap), we looked for something else.

Yahoo! Maps was the next step as they had a decent API and allowed more requests. Google currently allows 2,500 requests per day and Yahoo allows 5,000 requests (geocoding). Yahoo's maps were faster to load but we seemed to have nothing but issues with Google Chome throwing a YMAP Javascript error we could never track down. We didn't think it would be all that awesome telling Chrome users to clear their cache up to three times before the maps would load again (If you've had this issue and a have fix, for the love of all that is holy, let us know about it please).

After searching around for a day, we came across Leaflet. It was simple to implement and the maps were extremely fast to load compared to Google and Yahoo. You could also make the argument that they don't have nearly the traffic that Google and Yahoo have but Leaftlet was simple and it worked. Also, our scientific method for testing the load times was simply us reloading pages over and over as we worked on functionality. So don't expect any charts. Chris is an impatient guy, so if he gets annoyed by something he's built, it's not going live.

There is one issue we ran into with Leaflet and it has yet to be resolved. Their geocoding API, after about two weeks of use, started retuning funky results. By funky I mean, resolving Las Vegas, NV, to Livingston, Illinois. Dallas, TX would come back as being in Australia. Chris emailed their support team and they have confirmed it is a bug but they do not have an idea of when it will be resolved. Aside from that, their service has been fantastic.

It's already been done.

This is true, djangopeople.net was the inspiration for building djangopeople.me. We realized that djangopeople.net had been down for some time, intermittently. It was useful and we had both been contacted by people looking for Django developers through that site. So the original idea was to bring that functionality back and hopefully make it better.

Kenneth came across a posting on Convore when we were almost ready to launch the site. It appeared that a group of developers were getting together to bring djangopeople.net back online. We almost stopped working on the site as dp.net came back online for a short time. It was really slow and then ended up going back down a day later. So we decided to finish the small bug fixes we were working on and launch it.

So, just to be clear, djangopeople.me was inspired by djangopeople.net. We just wanted to bring that back to the Python/Django community. We believe the interface is better and faster. Also, using Twitter as the main auth system made it dead simple to sign up. We've had a few people ask for other authentication methods but at the moment Twitter provided exactly what we wanted with no hassle.

We use your Twitter username so it's very easy to find a profile of someone you already know and follow. This also makes it a little difficult to add other authentication methods as we'll now have to deal with allowing people to choose usernames and possibly picking a Twitter username that a future developer would sign up with. We're open to suggestions but we like the simplicity of using Twitter. Having recently wrapped up a project using the Facebook Python SDK, it was nice for Twitter's auth system to just work and not get in the way.

What's next?

We've had a good amount of people sign up and we've gotten some good feedback. We have a couple of ideas for tying into other Django services but we're waiting for replies to our emails at the moment. We both contract/freelance full time, so we'll probably spend the next week or two throwing ideas around before we know what the next step is. In the meantime, check out the site and let us know what you love and/or hate about it. We've got thick skins.