Django already makes it insanely easy to log a user in and out via their generic views.  Engineers will often want to create their own login view to provide some flexibility, say an Ajax login or other spin on standard login.  A number of examples are given in Django for that as well, and as with most of the framework this is a snap too.  A convenient feature of Django that doesn't make it into many of the examples I've seen is the AuthenticationForm that provides a convenience Django form with associated logic render a login form, validate input and throw errors if they do things like forget to supply a password and do the basic authentication check.

The form provides that all for you and all you really need to do in your view is read the user submitted data, validate the form and take the final step of logging the user in.

This is just one form in a group of 7 or so that provide all kinds of convenience features like Password Changes and User Registration.  Not only do they provide a developer with very easy access to common functions but they can extended or subclassed like any other Python Class to add or override functionality.

Here's an Example of a simple view method using the AuthenticationForm.  Something of a 'gotcha' for developers who normally use Django form is the POST values are passed as the second argument to the form.  The request object can be passed but that is normally only done to check for authentication cookies.  See the Source for more info on the form..  

from django.contrib.auth import login
from django.contrib.auth.forms import AuthenticationForm
from django.shortcuts import render
from django.shortcuts import HttpResponseRedirect
from django.core.urlresolvers import reverse

def authenticate_user(request):
    """Logs a user into the application."""

    if request.user.is_authenticated():
        return HttpResponseRedirect(reverse('account:index'))

    # Initialize the form either fresh or with the appropriate POST data as the instance
    auth_form = AuthenticationForm(None, request.POST or None)

    # Ye Olde next param so common in login.
    # I send them to their default profile view.
    nextpage = request.GET.get('next', reverse('account:index'))

    # The form itself handles authentication and checking to make sure passowrd and such are supplied.
    if auth_form.is_valid():
        login(request, auth_form.get_user())
        return HttpResponseRedirect(nextpage)

    return render(request, 'account/login.xhtml', {
        'auth_form': auth_form,
        'title': 'User Login',
        'next': nextpage,
    })

The associated template code for this renders the form and any errors if needed.  Note that the form may have individual field errors in the case of a blank username or password and returns a ValidationError if the credentials provided were invalid and this is dispalyed to the user via the 'non_field_errors' attribute if present.{% if auth_form.non_field_errors%}

    {% block message %}

        <div id="error_msg">

        {{ auth_form.non_field_errors }}

        </div>

    {% endblock %}

{% endif %}


{% block content-body %}

    <form action="{% url account:login-form %}" method="POST">

    {% csrf_token %}


        {% for field in auth_form %}

            <div class="fieldWrapper">

                {{ field.errors }}

                {{ field.label_tag }} {{ field }}

            </div>

        {%  endfor %}

    <input type="submit" value="Login" />

    <input type="hidden" name="next" value="{{ next }}" />

    </form>

    {{ ct }}

{%  endblock %}

Like many Djangonaughts I use django-pagination as my primary means to page results on lists pages and between the differences on the original Google project page(1.0.5 is the last downloadable version), what appears to be the same project migrated to GitHub and the PyPi (1.0.7 is the pip install version) site for the project, things can get confusing.

I'm probably the only person confused by this but it appear that the GitHub site is the most up to date and it appears to be in sync with the pip install version.  Life signs overall are dubious on the project though with no updates having come since early 2010 and several (what seem to be) reasonable pull requests sitting in the project queue.

One gotcha I wanted to point out in the PyPI readme file is the directions for TEMPLATE_CONTEXT_PROCESSORS:

According to the project documentation, in settings.py you should set:

TEMPLATE_CONTEXT_PROCESSORS= (
   "django.core.context_processors.auth",
   "django.core.context_processors.debug",
   "django.core.context_processors.i18n",
   "django.core.context_processors.media",
   "django.core.context_processors.request"
)

This can cause some problems in Django 1.3 however since the default TEMPLATE_CONTEXT_PROCESSORS have changed, in particular to support the new features for serving static media. 

So to include for pagination to work and to keep the default template context processors you should instead set:

TEMPLATE_CONTEXT_PROCESSORS = (
    "django.contrib.auth.context_processors.auth",
    "django.core.context_processors.debug",
    "django.core.context_processors.i18n",
    "django.core.context_processors.media",
    "django.core.context_processors.static",
    "django.contrib.messages.context_processors.messages",
    "django.core.context_processors.request",
)

Alternatively if you want to just extend the default template context processors with just the one you need for django-pagination to work you could simply:

TEMPLATE_CONTEXT_PROCESSORS = TEMPLATE_CONTEXT_PROCESSORS + ("django.core.context_processors.request",)

I always feel a bit dissatisfied with the amount of code I have to put in to process forms in Django views. Like most python developers it feels like I've gotten too complex it if takes me more than 5 or 6 lines of code to do something.   Previously I had coded seperate create and update views for form processing, partially this was to better control permissions but also because of the differences in dealing with bound and unbound forms as well as model instances.

This is my first stab at implementing that simple logic based on several examples I've seen out there in other blogs. 

@login_required
def post_edit(request, id=None):
    """
        Handles creating or updating of individual blog posts.

        :parm request: request object being sent to the view.
        :param id: post id, defaults to None if new post.
        
       """
    instance = None
    if id:
        instance = get_object_or_404(Post, id=id)

    title = "Create New Post"
    if instance:
        title = "Editing Post"

    # Create the form as needed.
    form = PostForm(request.POST or None, instance=instance) # Didn't work for me unles I passed k,v pair in instance.

    # Save the edited form if needed
    if request.method == 'POST' and form.is_valid(): # Validate and correct fields if needed.
        tmp_form = form.save(commit=False)
        # Set author to current user if none set.
        if not tmp_form.author:
            tmp_form.author = request.user.id
        # Set pub_date if none exist and post is published.
        if tmp_form.status == PUBLISHED_STATUS and not tmp_form.pub_date:
            tmp_form.pub_date = datetime.now()
        tmp_form.save()
        return HttpResponseRedirect(reverse('blog:post-edit', args=[tmp_form.id]))
        
    return render(request, 'blog/post_edit.xhtml', {
        'title': title,
        'form': form,
    })

So this allows me to call the same view in blog/urls.py and passing a post ID tell it if it's a new post or editing an old post.  The entry in urls.py is simply:

    url(r'^edit/(?P[0-9]+)/', 'post_edit', name='post-edit'),
    url(r'^delete/(?P[0-9]+)/', 'post_delete', name='post-delete'),

In the long run this wont be sufficient because I need to do more with the permissions, redesign my approach to producing pub dates (right now they matter because the slug needs to be unique for pub-date, not creation date).  But I feel like the approach is sound and going lean on forms is always the way to go.

There are a number of great new features in Django 1.3 for template developers.  Not the least of which is the addition of the STATIC_URL attribute in settings.py to help with referencing static media.

I found when trying to integrate social media linking in blog posts however that there wasn't a good way to pull the entire site domain into a URL without hard coding into the template.  Something that makes and descent Django developer shiver.

The easiest way around this is to use the .get_current() method of the Site model and access that via a custom template tag in your templates.  

The code itself is very simple:

from django import template

from django.contrib.sites.models import Site

register = template.Library()

@register.simple_tag
def sitedomain():
    '''Returns the URL of the default site.'''
    try:
        return Site.objects.get_current().domain
    except Site.DoesNotExist:
        return None

This makes it pretty easy to call in your template. I was able to use it to forward complete URLs onto some javascript functions that provides social linking in posts.