User profiles

Published November 24, 2007. Filed under: Django.

Django, as you hopefully already know, provides a way to store additional information related to a User via the mechanism of setting up a site-specific user profile model, and supports this directly via the get_profile() method on every User object.

By way of supporting this, back in version 0.2 of django-registration I added the ability to specify a callback function which, upon creating a new User, could also create a default site-specific profile for that User; at the time it seemed like a good way to handle the common situation of wanting to set up a profile for a user immediately upon signup. It has some limitations, though, primarily in that there’s no way to display a form for the user to fill in the initial values; instead, the callback function must be able to supply them on its own. Otherwise, you’d need to write your own form and view to handle filling out a profile.

And the more I thought about this, the more I felt that handling user profiles in any other way was really out of scope for a registration app; once you start adding more features related to profiles — creating, editing, etc. — you’re really getting outside of “user registration” and into some other territory. That’s why I never spent much time or effort working on more profile-related features for django-registration.

But for a project I’m working on right now, I’m going to need the ability to let users create, edit and view site-specific user profiles, and — as always — I couldn’t help thinking that this was something which needed to be handled generically. So Thursday night I sat down and wrote some code (which went quickly), and then yesterday and today I did some basic testing and wrote up some documentation (which went slowly). The result is the first public release of django-profiles; as always, it’s open source under the BSD license.

What it does

In terms of actual code, the app is pretty lightweight. It supplies four views, which cover the following functions:

The creation and editing views make use of some newforms trickery; they both allow you to specify your own newforms form class to be used, but if you don’t they’ll both fall back to automatically generating appropriate forms, either from the model class specified in the AUTH_PROFILE_MODULE setting (for initially creating the profile) or from the user’s existing profile (for editing).

The views also accept a number of useful keyword arguments for added flexibility, and there is support for allowing users to mark their profiles as “non-public”; if your profile model has a BooleanField for this option, you can pass its name to the latter two views, and it will be used to query only for public profiles.

What you should know

This code is less than forty-eight hours old; it was written quickly (about an hour or two of work all told) and, while it’s been through some tests to verify that the basic functionality works, it’s very much beta software and I expect that there will be bugs. The documentation also isn’t quite up to the standard I’d like, and I plan to work on that. If you can live with that and want to try it out, go grab a copy or get a Subversion checkout, and feel free to file bugs for any problems you run into.