Для обработки шаблона вам необходим контекст. Обычно это экземпляр django.template.Context, но в поставку Django также входит специальный подкласс — django.template.RequestContext, который работает немного иначе. Класс RequestContext по умолчанию добавляет группу переменных в контекст шаблона - такие как объект HttpRequest или информацию о текущем пользователе.

Используйте RequestContext когда вы не желаете указывать тот же набор переменных в серии шаблонов. Например, рассмотрим эти четыре представления:

from django.template import loader, Context

def view_1(request):
    # ...
    t = loader.get_template('template1.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am view 1.'
    })
    return t.render(c)

def view_2(request):
    # ...
    t = loader.get_template('template2.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am the second view.'
    })
    return t.render(c)

def view_3(request):
# ...
    t = loader.get_template('template3.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am the third view.'
    })
    return t.render(c)

def view_4(request):
    # ...
    t = loader.get_template('template4.html')
    c = Context({
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR'],
        'message': 'I am the fourth view.'
    })
    return t.render(c)

Следует отметить, что мы явно не используем сокращение render_to_response() — мы вручную загружаем шаблоны, конструируем объекты с контекстом и обрабатываем шаблоны. Мы делаем так с целью облегчения понимания вами этих примеров.

Каждое представление принимает три одинаковые переменные, app, user и ip_address, для своего шаблона. Неплохо было бы убрать эту избыточность.

Класс RequestContext и контекстные процессоры были созданы для решения этой задачи. Контекстные процессоры позволяют вам указывать ряд переменных, которые будут устанавливаться автоматически для каждого контекста, без необходимости их указания в каждом вызове render_to_response(). Надо лишь использовать RequestContext вместо Context при обработке шаблона.

Самый низкоуровневый метод использования контекстных процессоров заключается в создании нескольких процессоров и в передачи им RequestContext. Перепишем вышеприведённые примеры с использованием контекстных процессоров:

from django.template import loader, RequestContext

def custom_proc(request):
    "A context processor that provides 'app', 'user' and 'ip_address'."
    return {
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR']
    }

def view_1(request):
    # ...
    t = loader.get_template('template1.html')
    c = RequestContext(request, {'message': 'I am view 1.'},
            processors=[custom_proc])
    return t.render(c)

def view_2(request):
    # ...
    t = loader.get_template('template2.html')
    c = RequestContext(request, {'message': 'I am the second view.'},
            processors=[custom_proc])
    return t.render(c)

def view_3(request):
    # ...
    t = loader.get_template('template3.html')
    c = RequestContext(request, {'message': 'I am the third view.'},
            processors=[custom_proc])
    return t.render(c)

def view_4(request):
    # ...
    t = loader.get_template('template4.html')
    c = RequestContext(request, {'message': 'I am the fourth view.'},
            processors=[custom_proc])
    return t.render(c)

Разберём этот код:

В главе «Шаблоны» мы описали сокращение render_to_response(), которое позволяет вам не вызывать loader.get_template(), затем создавать Context, а затем вызывать метод render() для шаблона. Для того, чтобы продемонстрировать низкоуровневую работу контекстных процессоров, вышеприведённые примеры не используют сокращение render_to_response(). Но это возможно и предпочтительно. Сделаем это с помощью аргумента context_instance:

from django.shortcuts import render_to_response
from django.template import RequestContext

def custom_proc(request):
    "A context processor that provides 'app', 'user' and 'ip_address'."
    return {
        'app': 'My app',
        'user': request.user,
        'ip_address': request.META['REMOTE_ADDR']
    }

def view_1(request):
    # ...
    return render_to_response('template1.html',
        {'message': 'I am view 1.'},
        context_instance=RequestContext(request, processors=[custom_proc]))

def view_2(request):
    # ...
    return render_to_response('template2.html',
        {'message': 'I am the second view.'},
        context_instance=RequestContext(request, processors=[custom_proc]))

def view_3(request):
    # ...
    return render_to_response('template3.html',
        {'message': 'I am the third view.'},
        context_instance=RequestContext(request, processors=[custom_proc]))

def view_4(request):
    # ...
    return render_to_response('template4.html',
        {'message': 'I am the fourth view.'},
        context_instance=RequestContext(request, processors=[custom_proc]))

Здесь мы привели в порядок код обработки шаблона в каждой функции представления.

This is an improvement, but, evaluating the conciseness of this code, we have to admit we're now almost overdosing on the other end of the spectrum. FIXME. Мы убрали избыточность в данных (переменные нашего шаблона) за счёт добавления избыточности в код (в вызов processors). Использование контекстных процессоров не избавляет вас от необходимости набирать много строк кода.

По этим причинам Django предоставляет поддержку для глобальных контекстных процессоров. Параметр TEMPLATE_CONTEXT_PROCESSORS^[14] определяет то, какой процессор должен всегда применяться к RequestContext. Он исключает необходимость указания processors при каждом использовании RequestContext.

По умолчанию параметр TEMPLATE_CONTEXT_PROCESSORS определён так:

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

Этот параметр представляет собой кортеж вызываемых сущностей FIXME???, которые используют тот же интерфейс, что и вышеописанная функция custom_proc — функции, принимающие объект запроса и возвращающие словарь элементов, который затем включается в контекст. Следует отметить, что значения параметра TEMPLATE_CONTEXT_PROCESSORS указаны в виде строк, которые определяют процессоры (они должны быть доступны интерпретатору языка Python).

Процессоры применяются по порядку. Таким образом, если один процессор добавляет переменную в контекст, а затем второй процессор добавляет в контекст переменную с таким же именем, то второе значение перезапишет первое.

Django предоставляет ряд простых контекстных процессоров, включая активные по умолчанию: