Rationale
Imagine a shopping site where you had to sign up before you added things to your basket; you could certainly use it, but it would have to have strong incentives for you to bother rather than, say, use Amazon or another site where you can just get stuck straight into shopping. Of course, most shopping sites work like this, so you never really think about it.
But why should you have to register for any site before using it? (Beyond special cases.) You don't have to register before using Google, and you don't have to register before using the BBC News site; you also don't have to register before using Hunch, a site to help you make decisions that first has to get various pieces of information out of you so it can make useful suggestions. Deferred registration is a way of describing this, a phrase I've heard bandied around over the last year or so among web folk. But isn't it terribly difficult?
While at /dev/fort 2 back in June, we built a cooking site, where the main object is a recipe. Since we were building the site from scratch, and since it seemed like obviously the right thing to do, we used deferred registration: you can create recipes before you login or register, and later on they get stuck under the right user. We did this partly to convince ourselves that it really wasn't that difficult; and partly so we could convince other people ;-)
At some point we may put the code for the entire site online, but for now I've extracted what we wrote into a small re-usable extension to Django; it provides an easy way of storing objects in the session until we're ready to assign them to the correct user. Here, I'll describe how to use it in building a very simple website for keeping track of your present wishlist, in a manner similar to Things I Love.
"Deferred registration"?
It made sense to me calling this deferred registration, but it turns out it's more commonly called lazy registration.
Doing it in Django
We have a few assumptions here, and one is that you know how to use Django; I'm not going to go into great detail about the mechanics that are common to Django projects, since we can get that from the online documentation. I won't show every detail, and you won't end up with a fully-working wishlist system at the end of this, but hopefully you'll understand how to implement deferred registration. Additionally, I assume you're using the Django session middleware, and the standard auth system (in django.contrib.auth).
The code I've written is on github; this just needs to be on your PYTHONPATH somewhere.
Later on, I assume you're going to use Simon Willison's new django-openid (also on github), which while still a work-in-progress is sufficiently complete that it can be used here, and makes life a little easier. (The name is slightly misleading, as it doesn't just support OpenId, but provides a consistent workflow around registration and authentication.)
Creating our models
We'll have three main models: Wishlist, WishlistItem and WishlistPurchase. There isn't going to be anything hugely sophisticated about what we build here; let's just keep things very simple. (Actually, I'm not even going to touch the latter two; but the intention is that this is a just-enough-complicated example I can use it again in future.)
The key thing here is that SessionStashable is a mixin to the Model class; it augments the class (and the instantiated objects) with some useful methods for managing a list of objects in the session. If you're working with more than one stashable model, as we are here, you need to set session_variable to something different on each model. For now, that's all we need to do: your models are session-stashable straight off.
We're making wishlists and purchases stashable, but not wishlist items, because every item is already in a wishlist, so we know all the items were created by whoever created the wishlist. Note that created_by on both our stashable models is marked null=True, blank=True, because we need to be able to create them without a creator in the database.
Finally, I'm not showing the mechanism for generating slugs; I use another tiny Django plugin that takes care of this for me. Hopefully I'll be able to write about this in due course.
# wishlist.wishlists.models
from django.db import models
from django.contrib.auth.models import User
from django_session_stashable import SessionStashable
class Wishlist(models.Model, SessionStashable):
slug = models.CharField(max_length=255)
created_by = models.ForeignKey(User, null=True, blank=True)
name = models.CharField(max_length=255)
session_variable = 'wishlist_stash'
@models.permalink
def get_absolute_url(self):
return ('wishlist', (), { 'list_slug': self.slug })
def __unicode__(self):
return self.name
class WishlistItem(models.Model):
slug = models.CharField(max_length=255)
wishlist = models.ForeignKey(Wishlist)
name = models.CharField(max_length=255)
description = models.TextField()
def __unicode__(self):
return self.name
class WishlistItemPurchase(models.Model, SessionStashable):
item = models.ForeignKey(WishlistItem)
created_by = models.ForeignKey(User, null=True, blank=True)
created_at = models.DateTimeField(auto_now_add=True)
session_variable = 'purchase_stash'
def __unicode__(self):
if self.created_by:
return u"%s: %s @ %s" % (self.created_by, self.item, self.created_at)
else:
return u"%s @ %s" % (self.item, self.created_at)
Hopefully there's nothing unexpected there, and you're following along nicely.
Creating our views
I'm not going to bother showing all the views here, as the same techniques will apply to both stashable models. Let's set up urls.py as follows.
urlpatterns += patterns('',
url(r'^lists/$', 'wishlist.wishlists.views.list_list', name='wishlist-list'),
url(r'^lists/create/$', 'wishlist.wishlists.views.list_create', name='create-wishlist'),
url(r'^lists/(?P<list_slug>[a-zA-Z0-9-]+)/$', 'wishlist.wishlists.views.list_view', name='wishlist'),
url(r'^lists/(?P<list_slug>[a-zA-Z0-9-]+)/edit/$', 'wishlist.wishlists.views.list_edit', name='edit-wishlist'),
)
Anyone (including an anonymous user) can list wishlists; in a full application, we'd show your friends' lists, but for now we'll just show any you've created. You can then edit any wishlist you created (similarly for delete, not shown here).
Don't worry about the render function for the moment; we'll look at that further in a minute. For now, it's doing basically the same job as render_to_response.
# wishlist.wishlists.views
from django.http import HttpResponse, HttpResponseRedirect, HttpResponseForbidden
from django.shortcuts import get_object_or_404
from django.forms.models import ModelForm
from wishlist.wishlists.models import Wishlist
from wishlist.shortcuts import render, HttpResponseRedirect
class WishlistForm(ModelForm):
class Meta:
model = Wishlist
fields = ('name',)
def list_list(request):
if request.user.is_anonymous():
lists = Wishlist.get_stashed_in_session(request.session)
else:
lists = Wishlist.objects.filter(created_by=request.user)
return render(request, 'wishlists/list_list.html', { 'lists': lists })
def list_view(request, list_slug):
l = get_object_or_404(Wishlist, slug=list_slug)
if not l.viewable_on_this_request(request):
return HttpResponseForbidden("You're not allow to see this wishlist. Sorry!")
return render(request, 'wishlists/list_view.html', { 'list': l, 'editable': l.editable_on_this_request(request) })
def list_edit(request, list_slug):
l = get_object_or_404(Wishlist, slug=list_slug)
if not l.editable_on_this_request(request):
return HttpResponseForbidden("You're not allow to edit this wishlist. Sorry!")
if request.method=='POST':
form = WishlistForm(request.POST, instance=l)
if form.is_valid():
l = form.save()
return HttpResponseRedirect(l.get_absolute_url())
else:
form = WishlistForm(instance=l)
return render(request, 'wishlists/list_edit.html', {
'list': l,
'form': form,
})
def list_create(request):
if request.method=='POST':
form = WishlistForm(request.POST)
if form.is_valid():
list = form.save(commit=False)
if not request.user.is_anonymous():
list.created_by = request.user
list.save()
list.stash_in_session(request.session)
return HttpResponseRedirect(list.get_absolute_url())
else:
form = WishlistForm()
return render(request, 'wishlists/list_create.html', {
'form': form,
})
Again, nothing terribly complex. The list_list view pulls objects out of the session stash if you're an anonymous user (since once you've logged in or registered they'll just be marked as created by you). list_create does a tiny dance to set created_by if you're logged in, and stashes the request away (stash_in_session is careful not to stash anything if the object has something in created_by).
Notice that we haven't used anything like login_required, because this shuts off everything to users who haven't registered yet. Instead, we check whether the user can view or edit a wishlist, and return a HttpResponseForbidden object. (This looks a little ugly by default, although you can set things up to get a custom template rendered instead.) We've introduced two new methods into the Wishlist class: editable_on_this_request() and viewable_on_this_request(), which are needed so we can check the session if needed.
def viewable_on_this_request(self, request):
if self.created_by==None:
return self.stashed_in_session(request.session)
else:
return True
def editable_on_this_request(self, request):
if self.created_by==None:
return self.stashed_in_session(request.session)
else:
return self.created_by == request.user
In editable_on_this_request, if created_by is set it won't match the AnonymousUser, only a real authenticated one.
Reparenting on registration/login
Finally, on registration or login, we need to pass over the wishlists we've created (and wishlist purchases we've made, although we haven't discussed any of that side of the site) and reparent them to the user we now have. This is actually very easy, and takes two lines of code in a suitable view.
Wishlist.reparent_all_my_session_objects(request.session, request.user)
WishlistItemPurchase.reparent_all_my_session_objects(request.session, request.user)
Let's look at how this will work with django_openid. First, we modify urls.py.
from auth.views import registration_views
urlpatterns += patterns('',
(r'^login/$', registration_views, {
'rest_of_url': 'login/',
}),
(r'^logout/$', registration_views, {
'rest_of_url': 'logout/',
}),
(r'^account/(.*)$', registration_views),
)
Then we write our views file; django_openid uses a Strategy pattern, so all the views are tied into a single object.
# wishlist.auth.views
from django_openid.registration import RegistrationConsumer
from django_openid.forms import RegistrationForm
from django.conf import settings
from wishlist.wishlists.models import Wishlist, WishlistItemPurchase
from wishlist.shortcuts import render, HttpResponseRedirect
class RegistrationViews(RegistrationConsumer):
def on_registration_complete(self, request):
Wishlist.reparent_all_my_session_objects(request.session, request.user)
WishlistItemPurchase.reparent_all_my_session_objects(request.session, request.user)
return HttpResponseRedirect('/')
def on_login_complete(self, request, user, openid=None):
Wishlist.reparent_all_my_session_objects(request.session, request.user)
WishlistItemPurchase.reparent_all_my_session_objects(request.session, request.user)
return HttpResponseRedirect('/')
def render(self, request, template_name, context = None):
context = context or {}
return render(request, template_name, context)
registration_views = RegistrationViews()
In practice you'll want to do more work here. For a start, there are lots of templates you'll need, although django_openid ships with ones that may be suitable for you. But this shows the bits that matter to us: two hook methods, on_registration_complete and on_login_complete, which are the right place to reparent all our stashed objects. It also makes django_openid use our render function — and now it's time to look at that.
Warning users of unparented objects
One final touch: it's nice to give a hint to people who haven't registered or logged in that they will lose their wishlists unless they do. Since we want to put this message on every single page, it needs to be done centrally, at the point that we render our templates. This is where the render function we've been using comes in.
# wishlist.shortcuts
from django.template import RequestContext
from django.shortcuts import render_to_response
from django.http import HttpResponseRedirect
def render(request, template_name, context=None):
from wishlist.wishlists.models import Wishlist, WishlistItemPurchase
context = context or {}
context['stashed_wishlists'] = Wishlist.num_stashed_in_session(request.session)
context['stashed_purchases'] = WishlistItemPurchase.num_stashed_in_session(request.session)
return render_to_response(
template_name, context, context_instance = RequestContext(request)
)
Using a central function like this means that we can have a number of variables appear in the render context for every template rendered. In this case, we just have two: stashed_wishlists and stashed_purchases. We can then use them to show a brief warning. This would go in a base template (so all other templates would need to use {% extends "base.html" %} or similar).
{% if stashed_wishlists %}
<div id="notifications" class="receptacle">
<div class="section">
<p><em>Warning</em>: you have <a href="{% url wishlist-list %}">unsaved wishlists</a>!
<a href="/account/register/">Register</a> or <a href="/login/">log in</a> to keep them forever.</p>
</div>
</div>
{% endif %}
There isn't much to say here at all. (Except, okay, the HTML could be simpler; but this is all taken from a running app, in the hope it will avoid introducing bugs.)
Going further
You can use the same approach for things like comments; store the comment with no creator, stash it in the session, and come back to it later. With care, and some thought, you can apply this technique to most things that might need deferred registration.
It's a good idea to plan all the interactions around deferred registration before you start coding (which goes against the instincts of a lot of developers). As well as the code behind creation and reparenting, it can have an impact on how your pages fit together, and the interaction elements on those pages. You also have to pay attention when you render lists of things that can be created in this way, so you either don't display those waiting for a real creator, or alter the display suitably so you don't show text like created by None
. If the latter, you may want to open up the display page to more than just the creator.
Despite a little bit more work up front, it shouldn't take much longer overall to get this right. Don't believe me? Grab the code and try using it next time you build a site.