Standard URL Configuration

Django doesn’t provide any features for automatically discovering or generating a URL structure for any site. Instead, each site and application is expected to explicitly declare whatever addressing scheme is most appropriate using URL configurations. This isn’t a limitation—it’s a feature that allows you to define your site’s addresses the way you’d like. After all, sites on the Web are like real estate; your Web framework shouldn’t determine your floor plan.

Defining a URL configuration may seem quite simple, but there’s a bit going on that merits some special attention, especially since Django’s own tools aren’t the only way to define this configuration. The implementation lives at django.conf.urls.defaults and provides two functions that work together to manage URL configurations.

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^$', 'post_list'),
    (r'^(?P<id>d+)/$', 'post_detail'),
    (r'^(?P<id>d+)/comment/$', 'post_comment', {'template': 'comment_form.html'}),
)

The url( ) Function

In an effort to provide better flexibility in the long run, URL pattern tuples have been deprecated in favor of the url() utility function. url() takes the same arguments that are passed into the tuple, but can also take an extra keyword argument to specify the name of the URL pattern being described.

This way, a site can use the same view multiple times, yet still be able to be referenced using reverse URL lookups. More information on that can be found later in this section.

The include( ) Function

Rather than supplying all your URL patterns in a single file, the include() function allows them to be split up among multiple files. It takes a single argument: an import path where another URL configuration module can be found. This not only allows the URL configuration to be split across multiple files, but it also allows the regular expression to be used as a prefix for the included URL patterns.

One important thing to remember when using include() is to not specify the end of the string in the regular expression. The expression should never end in a dollar sign ($). The dollar sign ($) causes the expression to only match the full URL. This wouldn’t leave any additional URL fragments to pass along to the included configuration. This means that the extra URL patterns would only be matched if they check specifically for an empty string.

Resolving URLs to Views

Views are rarely called directly by your own code but are instead invoked by Django’s URL dispatch mechanism. This allows views to be decoupled from the particular URLs that trigger them, and the details of how those two aspects are linked can be safely ignored for most projects. But since views don’t always have to just be simple functions, knowing how Django goes from URL to view is important in order to determine what views are truly capable of.

Mapping URLs to views is a simple, well-documented process, but it’s worth covering the basics here for reference. A typical URL pattern consists of a few distinct items:

• A regular expression to match against the incoming URL being requested
• A reference to the view to be called
• A dictionary of arguments to be passed along every time the view is accessed
• A name to be used to reference the view during reverse lookups

Since URL patterns are expressed in regular expressions, which can capture certain portions of a string for later use, Django uses this as a natural way to pull arguments out of a URL so they can be passed to a view. There are two ways these groups can be specified, which determine how their captured values are passed into the view.

If groups are specified without names, they’re pulled into a tuple, which is passed along as excess positional arguments. This approach makes the regular expression a bit smaller, but it has some drawbacks. Not only does it make the regular expression a bit less readable, it also means that the order of arguments in your view must always match the order of the groups in the URL, because Django sends them in as positional arguments. This couples the URL to the view more than is usually preferable; in some situations, such as the object-based views described later in this chapter, it can still be quite useful.

If groups are given names, Django will create a dictionary mapping those names to the values that were extracted from the URL. This alternative helps encourage looser coupling between URLs and views by passing captured values to the view as keyword arguments. Note that Django doesn’t allow named and unnamed groups to be used together in the same pattern.

Resolving Views to URLs

As alluded to in the previous section, there’s another URL resolution process that Django provides, which can be of even more use if applied properly. Applications often need to provide links or redirects to other parts of the application or elsewhere on the site, but it’s not usually a good idea to hard-code those links directly. After all, even proprietary applications can change their URL structure, and distributed applications may not have any idea what the URL structure looks like in the first place.

In these situations, it’s important to keep the URLs out of the code. Django offers three distinct ways to specify a location without needing to know its URL in advance. Essentially, these all work the same way, as they all use the same internal machinery, but each interface is suited for a particular purpose.

from django.conf.urls.defaults import *
from django.views.generic.detail import DetailView
from library.import models
 
class LibraryDetail(DetailView):
    queryset = models.Article.objects.all()
 
urlpatterns = patterns('django.views.generic',
    url(r'^articles/(?P<object_id>d+)/$', LibraryDetail.as_view(),
        name='library_article_detail'),
)

from django.db import models
 
class Article(models.Model):
    title = models.CharField(max_length=255)
    slug = models.SlugField()
    pub_date = models.DateTimeField()
 
    def get_absolute_url(self):
        return ('library_article_detail',
            (), {'object_id': self.id})
    get_absolute_url = models.permalink(get_absolute_url)

{% url library_article_detail object_id=article.id %}

>>> from django.core.urlresolvers import reverse
>>> reverse('library_article_detail', kwargs={'object_id': 1})
'/articles/1/'

Templates Break It Up a Bit

Django’s views do perform the basic function of the output interface, because they’re responsible for the response that is sent to the browser. In a strict sense, this response is the entire output, and it contains all the information about what the user will see. This is often too much work to do in Python while still making it readable, so most views rely on templates to generate the bulk of the content.

The most common practice is to have each view call a single template, which may make use of a number of tools to minimize the amount of template code that must be written for use by a particular view. Chapter 6 includes further details on the template language and the tools that can be used, but the important thing to know for this section is that templates are a great way to simplify the coding process as a whole. They help cut down on the amount of code that must be written, while simultaneously making that code more readable and maintainable for the future.

While Chapter 1 listed templates as a separate layer, remember that they’re really just a tool that Django makes available to other parts of an application, including views. Ultimately, whether or not templates are used to generate content, the view alone is responsible for generating the final response. Django’s template system has no concept of requests or responses; it just generates text. It’s up to views to handle the rest.

Anatomy of a View

A view is a function that takes an HTTP request and returns an HTTP response. That is a bit simplistic, given the potential power of views, but that’s really all there is to it. A view always receives, as its first argument, the HttpRequest created by Django, and it should always return an HttpResponse, unless something went wrong. Full details on those objects, their purpose and their properties are covered in Chapter 7.

The first aspect of that definition is the notion that a view must be a standard function. This definition is a bit flexible because in reality, any Python callable can be used as a view; it just happens that basic functions are easy to work with and provide everything that’s necessary for most situations. Methods—both on classes and instances—and callable objects, using the protocol described in Chapter 2, are all perfectly valid for use as views. This opens up a variety of other possibilities, some of which will be described later in this chapter.

The next point is the one immutable when it comes to views. Whenever a view is called, regardless of what other arguments are passed along, the first argument is always an HttpRequest object. This also means that all views must accept at least this one object, even those views that don’t have use for any explicit arguments. Some simple views, such as those that display the server’s current time, may not even use the request object, but must always accept it anyway to fulfill the basic protocol of a view.

On the subject of arguments, another point is that a view must be able to accept whatever arguments are passed to it, including those captured from the URL and those passed into the site’s URL configuration. This may seem obvious, but a common point of confusion is the presumption that Django uses some kind of magic to allow a URL configuration to specify which template should be used, without requiring any supporting code in the view.

Django’s generic views all allow you to specify the template name, and many users assume that Django somehow passes this straight through to the template system to override whatever name the view uses by default. The truth is that the generic views have special handling for this argument, and the view itself is responsible for telling the template system which template to use. Django relies on standard Python, so there’s no magic behind the scenes that tries to interpret what your arguments are supposed to mean. If you plan to supply an argument to a function, make sure that the view knows how to deal with it.

The last notion from that original description of views is that a view must return an HttpResponse object, and even that isn’t entirely accurate. Returning a response is definitely the primary goal of all views, but in certain situations it’s more appropriate to raise an exception, which will be handled in other ways.

What goes on between request and response is largely unrestricted, and views can be used for as many purposes as there are needs to be met. Views can be built to serve a specific purpose or they can be made generic enough to be used in distributed applications.

Writing Views to Be Generic

A common theme in Django development is to make code as reusable and configurable as possible so that applications and snippets are useful in more than one situation, without having to rewrite code for every need. That’s the whole point of DRY: Don’t Repeat Yourself.

Views present a bit of a challenge with regards to DRY, since they’re only called by incoming requests. It may seem like it wouldn’t be possible to write a view that could be called for anything other than the request it was originally intended for. Django itself, however, is full of examples of generic views, which can be used for a variety of applications and situations with only a small amount of configuration necessary for each new use.

There are a few guidelines that can greatly aid the reuse of views, making them generic enough to be used throughout a variety of applications. Views can even be made so generic that they can be distributed to others and included in projects the original author had no concept of.

from django.shortcuts import render_to_response
from django.template import RequestContext
 
from blog.models import Post
 
def show_post(request, id):
    post = Post.objects.get(id=id)
    context = RequestContext(request, {'post': post})
    return render_to_response('blog/detail.html', context)

from django.shortcuts import render_to_response
from django.template import RequestContext
 
def show_object(request, id, model, template_name):
    object = model._default_manager.get(pk=id)
    context = RequestContext(request, {'object': object)})
    return render_to_response(template_name, context)

from django.conf.urls.defaults import *
 
from blog.models import Post
 
urlpatterns = patterns('',
    (r'^post/(?P<id>d+)/$', 'blog.views.show_object', {
        'model': Post,
        'template_name': 'blog/detail.html',
    }),
)

r'^album/(?P<id>[a-z]+-[0-9])/$'

View Decorators

Most boilerplate in views is either at the very beginning or the very end. Usually it handles such tasks as initializing various objects, testing standard prerequisites, handling errors gracefully or customizing the response before it goes out to the browser. The real meat of the view is what sits in the middle, and that’s the part that’s fun to write. Described in Chapter 2, decorators are a great way to wrap several functions in some common code that can be written once and tested easily, which reduces both bugs and programmer fatigue. Since views are typically just standard Python functions, decorators can be used here as well.

Chapter 2 illustrated how decorators can be used to write a wrapper around the original function, which can then access all the arguments that were intended for that function, as well as the return value from the function itself. In terms of views, this means that decorators always have access to the incoming request object and the outgoing response object. In some cases, a decorator can be special-cased for a particular application, which would allow it to anticipate a greater number of arguments that are specific to that application.

There are a number of things decorators can offer views, and a few of them are common enough to warrant inclusion in Django itself. Living at django.views.decorators are a few packages containing decorators you can use on any view in any application. The following packages are listed with just the trailing portion of their full import path provided, given that they all live at the same location.

• cache.cache_page—Stores the output of the view into the server’s cache so that when similar requests come in later, the page doesn’t have to be re-created each time.
• cache.never_cache—Prevents caching for a particular view. This is useful if you have site-wide caching set up but certain views can’t afford to go stale.
• gzip.gzip_page—Compresses the output of the view and adds the appropriate HTTP headers so the Web browser knows how to handle it.
• http.conditional_page—Only sends the whole page to the browser if it has changed since the last time the browser got a copy of it.
• http.require_http_methods—Accepts a list of HTTP methods (described in detail in Chapter 7) that the view is limited to. If the view is called with any other method, it sends a response telling the browser it’s not allowed, without even calling the view. Two included shortcut variations are http.require_GET and http.require_POST, which don’t take any arguments and are hard coded for GET and POST requests, respectively.
• vary.vary_on_header—Helps control browser-based caching of pages by indicating that the page’s content changes, depending on the values of the headers passed into the decorator. A simple variant specific to the Cookie header is available at vary.vary_on_cookie.

Additional decorators are provided as part of the bundled applications living at django.contrib. These decorators all live below that path, so as in the previous list, only the relevant path is supplied:

• admin.views.decorators.staff_member_required—A simple decorator that checks the current user to see if it has staff access. This is used automatically for all the views in Django’s built-in admin, but could also be used for any other staff-only views on your site. If the user doesn’t have staff permissions, the decorator redirects the browser to the admin’s login page.
• auth.decorators.user_passes_test—Accepts a single argument, which is a function to test the current user against some arbitrary condition. The provided function should accept just the User object and return True if the test passes or False if it fails. If the test passes, the user will be granted access to the page, but if it fails, the browser will redirect to the site’s login page, as determined by the LOGIN_URL setting.
• auth.decorators.login_required—A specialized version of user_passes_test, this decorator simply checks that the user is logged in before allowing access to the view.
• auth.decorators.permission_required—Another specialization of user_passes_test, this checks that the user has a given permission before the view is loaded. The decorator takes a single argument: the permission to be checked.

These are just the decorators that are bundled with Django itself. There are many other purposes for decorators, and third-party applications can provide their own as well. In order for these decorators to be of any use, however, they must be applied to views.

from django.conf.urls.defaults import *
from django.contrib.auth.decorators import login_required
from thirdpartyapp.views import special_view
 
urlpatterns = patterns('',
    (r'^private/special/$', login_required(special_view)),
)

from django.utils.functional import wraps
 
def set_test_cookie(view):
    """
    Automatically sets the test cookie on all anonymous users,
    so that they can be logged in more easily, without having
    to hit a separate login page.
    """
    def wrapper(request, *args, **kwargs):
        if request.user.is_anonymous():
            request.session.set_test_cookie()
        return view(request, *args, **kwargs)
    return wraps(view)(wrapper)

from django.utils.functional import wraps
from django.shortcuts import get_object_or_404
 
from news.models import Article
 
def get_article_from_id(view):
    """
    Retrieves a specific article, passing it to the view directly
    """
    def wrapper(request, id, *args, **kwargs):
        article = get_object_or_404(Article, id=int(id))
        return view(request, article=article, *args, **kwargs)
    return wraps(view)(wrapper)

from django.utils.functional import wraps
 
def content_type(c_type):
    """
    Overrides the Content-Type provided by the view.
    Accepts a single argument, the new Content-Type
    value to be written to the outgoing response.
    """
    def decorator(view):
        def wrapper(request, *args, **kwargs):
            response = view(request, *args, **kwargs)
            response['Content-Type'] = c_type
            return response
        return wraps(view)(wrapper)
    return decorator

@content_type('application/json')
def view(request):
    ...

from datetime import datetime
 
from django.db import models
 
class Entry(models.Model):
    path = models.CharField(max_length=255)
    type = models.CharField(max_length=255, db_index=True)
    date = models.DateTimeField(default=datetime.utcnow, db_index=True)
    description = models.TextField()

from django.utils.functional import wraps
 
from mylogapp.models import Entry
 
def logged(view):
    """
    Logs any errors that occurred during the view
    in a special model design for app-specific errors
    """
    def wrapper(request, *args, **kwargs):
        try:
            return view(request, *args, **kwargs)
        except Exception as e:
            # Log the entry using the application’s Entry model             Entry.objects.create(path=request.path,
                                 type='View exception',
                                 description=str(e))
 
            # Re-raise it so standard error handling still applies
            raise
    return wraps(view)(wrapper)

django.views.generic.base.View

The easiest way to get the basics into your class is to subclass Django’s own View class. It won’t do everything you’ll need out of the box, of course, but it provides the basics:

• Validates arguments passed into the view configuration
• Prevents using arguments named after HTTP methods
• Collects arguments passed in the URL configuration
• Keeps request information in a convenient place for methods to access
• Verifies that a requested HTTP method is supported by the view
• Automatically handles OPTIONS requests
• Dispatches to view methods based on the requested HTTP method

Some of this functionality is specific to it being a class, such as making convenient request information conveniently available to various view methods. Others, such as enforcing specific HTTP methods and handling OPTIONS requests directly, are really just good HTTP practices that are made easier by the fact that a class can provide such functionality without you having to remember to defer to it in your own code.

Classes offer a chance for multiple methods to interact, so Django uses a few standard methods to do the common items, while providing you a way to add in other methods that now only need to worry about the specifics of your application. And since it’s just a class, you can also add other methods as you see fit. Django won’t do anything with them, so you’ll have to call them yourself, but it does give you a chance to abstract out common code more easily than if you were working with raw functions.

All of Django’s generic views inherit from a common ancestor to provide all these hooks, and it’s easy for yours to do the same. Let’s take a look at some of the methods Django provides on a default generic view.

from django.views.generic.base import View 
 
urlpatterns = patterns('',
    (r'^example/', View.as_view(template_name='example.html')),
)

def view(request, template_name='form.html'):
    if request.method == 'POST':
        form = ExampleForm(request.POST)
        if form.is_valid():
            # Process the form here
            return redirect('success')
        else:
            return render(request, template_name, {'form': form})
    else:
        form = ExampleForm()  # no data gets passed in
        return render(request, template_name, {'form': form})

class FormView(View):
    template_name = 'form.html'
 
    def get(self, request):
        form = ExampleForm()
        return render(request, self.template_name, {'form': form})
 
    def post(self, request):
        form = ExampleForm(request.POST)
        if form.is_valid():
            # Process the form here
            return redirect('success')
        else:
            return render(request, self.template_name, {'form': form})

Decorating View Methods

The structure of these class-based views makes them somewhat interesting when it comes to decorators. On one hand, they’re classes, which can’t be decorated using the same decorators that are used for functions. In fact, classes can’t be decorated at all prior to Python 3. On the other hand, the as_view() method returns a simple function, which can be decorated just like any other.

The simplest technique to explain is decorating the output of as_view(). Because it returns a function, it can be decorated just like any other function. So if you need to require a user to be logged in, you can simply use the standard login_required decorator, as always.

from django.contrib.auth.decorators import login_required
 
urlpatterns = patterns('',
    (r'^example/', login_required( FormView.as_view(template_name='example.html'))) ,
)

On the other hand, you can decorate individual methods on your class directly, if you know of things that they’ll always need. Two things complicate matters more than the typical function case. First, these are instance methods, rather than simple functions, which means they accept a self argument, which isn’t there on traditional function-based views. As is often the case with problems regarding decorators, the solution is another decorator, which is in this case provided by Django itself. The method_decorator can be used to wrap a normal decorator in a way that lets it ignore self and just deal with the argument it expects.

from django.utils.decorators import method_decorator
 
class FormView(View):
    @method_decorator(login_required)
    def get(request):
        # View code continues here

The second issue is that there are now multiple functions involved, rather than just one that can be decorated directly. You can decorate any of the functions you’d like, but an interesting fact of the dispatching process for class-based views is that dispatch() is the only method that serves the same purpose as a traditional function. All requests go through it, and it also has access to all available information about the class, the instance and the incoming request.

Therefore, this is also the best place to apply any view decorators. If you apply a decorator to dispatch(), it’ll modify the behavior of every request, regardless of what other methods are used afterward. You can decorate individual methods if you have a good reason to, but it’s most useful to use dispatch() and have it work the same way it does in traditional function-based views.

Using an Object As a View

As described in Chapter 2, Python provides a way to define a class in such a way that instances of it can be called as if they were functions. If defined on a class, the __call__() method will be called when the object is passed in where a function is expected. As with any other callable, such objects can also be used as Django views.

There are as many ways to use objects as views as there are ways to define objects themselves. Aside from using __call__() to receive each incoming request, what happens inside the object is up for grabs. In a typical situation, the request would be dispatched to individual methods, similar to Django’s own class-based views, but you can do whatever you need.

Cross-Origin Resource Sharing (CORS)

Requests that cross from one domain to another are a security risk, because they could expose sensitive data to sites that shouldn’t have access to that data. Imagine if a random blog could just make an AJAX call to your bank’s website. If you were logged in and didn’t have any protection in your browser, that call could send your bank account information to a blog you know nothing about and just happened to visit.

Thankfully, modern browsers do have protection against this sort of thing. By default, requests made from one site to another within your browser will be forbidden. There are legitimate uses for cross-origin requests like that, though, such as between trusted sites or when serving public data files for general use. The Cross-Origin Resource Sharing (CORS) specification allows one site to indicate which other sites can access certain resources.

CORS Decorator

With a traditional function-based view, this functionality can be added as a decorator. Here’s how you could decorate a view to make it publicly available from any site that requests it:

@cross_origin(allow_origin=['*'])
def public_data(request):
    # Data retrieval goes here

The implementation is pretty straightforward, as far as decorators go:

def cross_origin(allow_credentials=False, allow_headers=None,
                 allow_methods=None, allow_headers=None,
                 allow_origin=None, expose_headers=None, max_age=None):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(request, *args, **kwargs):
            headers = {}
 
            if access_control_allow_credentials:
                headers['Allow-Credentials'] = allow_credentials
            if access_control_allow_headers:
                headers['Allow-Headers'] = ', '.join(allow_headers)
            if access_control_allow_methods:
                headers['Allow-Methods'] = ', '.join(allow_methods)
            if access_control_allow_origin:
                headers['Allow-Origin'] = ' '.join(allow_origin)
            if access_control_expose_headers:
                headers['Expose-Headers'] = ', '.join(expose_headers)
            if access_control_max_age:
                headers['Max-Age'] = self.max_age
 
            response = func(request, *args, **kwargs)
 
            for name, value in headers:
                response.headers['Access-Control-%s' % name] = value
 
            return response
        return wrapper
    return decorator

There’s no need to support using the decorator without arguments, because if you don’t supply any arguments, it wouldn’t do anything anyway. So it only supports arguments and simply has to add all the right headers when the response comes back from the decorated view. As you can see, some of them accept lists, while others accept just a single value.

CORS Mixin

This decorator could be applied to a class-based view directly, using method_decorator, but to make it a bit easier to configure, we could instead use a mixin. Here’s how it would look on a similarly featured class-based view:

class PublicData(View, CrossOrigin): 
    access_control_allow_origin = ['*']
 
    def get(self, request):
        # Data retrieval goes here

The implementation gets a little more complicated than a simple decorator, but it’s still pretty simple to work with:

class CrossOrigin(object):
    """
    A view mixin that provides basic functionality necessary to add the necessary
    headers for Cross-Origin Resource Sharing
    """
 
    access_control_allow_credentials = False
    access_control_allow_headers = None
    access_control_allow_methods = None
    access_control_allow_origin = None
    access_control_expose_headers = None
    access_control_max_age = None
 
    def get_access_control_headers(self, request):
        headers = {}
 
        if self.access_control_allow_credentials:
            headers['Allow-Credentials'] = self.access_control_allow_credentials
        if self.access_control_allow_headers:
            headers['Allow-Headers'] = ', '.join(self.access_control_allow_headers)
        if self.access_control_allow_methods:
            headers['Allow-Methods'] = ', '.join(self.access_control_allow_methods)
        if self.access_control_allow_origin:
            headers['Allow-Origin'] = ' '.join(self.access_control_allow_origin)
        if self.access_control_expose_headers:
            headers['Expose-Headers'] = ', '.join(self.access_control_expose_headers)
        if self.access_control_max_age:
            headers['Max-Age'] = self.access_control_max_age
 
        return headers
 
    def dispatch(self, request, *args, **kwargs):
        response = super(CORSMixin, self).dispatch(request, *args, **kwargs)
 
        for name, value in self.get_access_control_headers(request):
            response.headers['Access-Control-%s' % name)] = value
 
        return response

Worth noting here is that the header functionality has been moved out into a separate method, which receives the request as an argument. This allows you to override that method in your subclass, in case you need to make changes to the CORS headers based on details of the incoming request.

For example, if you had a lot of different domains that need access to the resource, you could check the incoming request against those domains and only add that domain as an allowed origin, rather than having to include the entire list in every response. This is a prime example of how classes enable greater customization of internal details than a decorator, which tends to hide those implementations in a way that you can’t modify.

Providing Both a Decorator and a Mixin

If you wanted to supply this as a reusable helper, you might even want to supply both the function decorator and the class mixin. This is easy to do by just pulling the common code out into a separate function, which can be called from each of the different approaches.

def cors_headers(allow_credentials=false, allow_headers=None, allow_methods=None,                 allow_origin=None, expose_headers=None, max_age=None):
    headers = {}
 
    if allow_credentials:
        headers['Access-Control-Allow-Credentials'] = allow_credentials
    if allow_headers:
        headers['Access-Control-Allow-Headers'] = ', '.join(allow_headers)
    if allow_methods:
        headers['Access-Control-Allow-Methods'] = ', '.join(allow_methods)
    if allow_origin:
        headers['Access-Control-Allow-Origin'] = ' '.join(allow_origin)
    if expose_headers:
        headers['Access-Control-Expose-Headers'] = ', '.join(expose_headers)
    if max_age:
        headers['Access-Control-Max-Age'] = self.max_age
 
    return response
 
def cross_origin(allow_credentials=false, allow_headers=None, allow_methods=None,
                 allow_origin=None, expose_headers=None, max_age=None):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(request, *args, **kwargs):
            response = func(request, *args, **kwargs)
            headers = cors_headers(response, allow_credentials, allow_headers,
                                   allow_methods, allow_origin, expose_headers, max_age)
            response.headers.update(headers)
            return response
        return wrapper
    return decorator
 
class CrossOrigin(object):
    """
    A view mixin that provides basic functionality necessary to add the necessary
    headers for Cross-Origin Resource Sharing
    """
 
    access_control_allow_credentials = false
    access_control_allow_headers = None
    access_control_allow_methods = None
    access_control_allow_origin = None
    access_control_expose_headers = None
    access_control_max_age = None
 
    def get_access_control_headers(self, request):
        return cors_headers(self.access_control_allow_credentials,
                            self.access_control_allow_headers,
                            self.access_control_allow_methods,
                            self.access_control_allow_origin,
                            self.access_control_expose_headers,
                            self.access_control_max_age):
 
    def dispatch(self, request, *args, **kwargs):
        response = super(CORSMixin, self).dispatch(request, *args, **kwargs)
        headers = self.get_access_control_headers(request)
        response.headers.update(headers)
        return response

Now the only thing that the decorator and mixin have to do is collect arguments appropriately for each technique, leaving the details of applying the actual headers to a common function. This isn’t a groundbreaking technique, but it’s useful to see how decorators and mixins aren’t that different after all. They’re configured a bit differently, but in the end it still comes down to accepting a request and returning a response.