В Django версии 1.3 были представлены class-based views — способ описания view в виде классов. Документация, однако, касается только generic views, не описывая общую технику написания «вьюх» в виде классов. Начав использовать generic views и затем пытаясь изменить их поведение, я постепенно дошел до того момента, когда мне пришлось смотреть исходный код, чтобы понять, как что-то сделать. Поэтому я решил написать этот текст. Цель его — объяснить, как использовать class-based view и чем это может быть полезно.

Мотивация

Идея проста — есть некоторый часто используемый функционал (например, отображение объекта/списка объектов из БД, передача контекста в шаблон, и т.п.), который используется очень часто. Чтобы не приходилось писать однообразный код, подобные view описаны прямо в коде фреймворка. Для того, чтобы использовать их, нужно сообщить только специфические параметры, вроде типа объекта или имени шаблона, в который передавать контекст.

Например, у нас есть класс Publisher, и нам хочется отобразить на странице список всех объектов этого класса. В Django 1.2 мы используем generic view так:

# urls.py
from django.views.generic import list_detail
from books.models import Publisher

urlpatterns = patterns('',
    (r'^publishers/$', list_detail.object_list, {
         "queryset" : Publisher.objects.all(),
    })
)

Мы просто передаем в словарь параметров интересующий нас queryset, все остальное уже реализовано за нас.

Однако если в процессе разработки обнаруживается необходимость поменять поведение «вьюхи», изначально реализованной как generic (что бывает довольно часто), возникают проблемы:

1. В generic view не предусмотрены параметры, меняющие интересующее поведение.
2. Код, формирующий параметры для generic view, сравним по объему с кодом отдельно написанной «вьюхи», и лежит в URLCONF, где ему явно не место.

Хочется иметь технологию, позволяющую использовать готовый фунционал Django для написания view, при этом имея возможность изменять его поведение в любой части.

Generic views на классах

Для того, чтобы в generic views можно было менять все, что угодно, разработчики решили представлять их в виде классов, в которых основные параметры представлены полями, а фунционал наглядно разбит на функции — отдельно диспетчеризация, отдельно формирование контекста, отдельно рендеринг шаблона (подробнее об этом см. ниже). От такого класса можно наследовать свои view, и перекрывать в них переменные и функции вместо передачи их в параметрах. Так выгладит реализация примера с Publisher на классах:

# views.py
from django.views.generic import DetailView
from books.models import Publisher

class PublisherDetailView(DetailView):
    model = Publisher

В urls.py же вместо названия «вьюхи» теперь передается метод as_view() описанного класса:

urlpatterns = patterns('',
    (r'^publishers/$', PublisherDetailView.as_view(),
)

В качестве параметров этой фунции могут быть переданы переменные типа model или template_name, аналогично тому, как это делалось с function-based views.

Теперь, если нам нужно будет, например, поменять контекст, передаваемый в шаблон, можно просто переопределить в этом классе фунцию get_context_data(), которая занимается формированием контекста. И код будет жить там, где ему полагается — во views.py. Осталось только разобраться с тем, какие функции в каких generic view есть, и что они делают.

Примеси

Ответы на вопросы о том, как вы хотите обработать параметры входящего запроса, как будете выбирать данные из БД и как будете формировать ответ часто не зависят друг от друга. Иногда, вам хочется выдать в качестве ответа HTML страницу, иногда — JSON-объект. Если вы хотите написать общий код для обработки запроса и работы с БД, который будет использоваться с обоих случаях, нужно как-то выделить группу всех методов, отвечающих за формирование ответа из контекста. Такую проблему можно решить с помощью паттерна примесей (mixins).

Каждая class-based generic view:

1. Наследуется от базового класса View;
2. Наследуется от одной или нескольких примесей.

Итак, для расширения фунционала generic view нужно:

1. Посмотреть в документации, какие примеси она содержит;
2. Найти в этих примесях ту фунцию, в которой реализовано интересующее вас поведение;
3. Переопределить эту фунцию.

Все «вьюхи» как классы

Использование class-based generic views мотивирует писать все «вьюхи» в виде классов, все из тех же соображений снижения повторяемости и структуризации. Если из function-based generic views вам часто не подходила ни одна — по причинам, описанным выше, то из class-based generic views вам всегда будет полезен View.

View

Все generic views наследуются от этого класса. В нем реализована функция dispatch(), принимающая request и возвращающая HttpReponse, собственно то, что и делала всегда view, будучи фунцией. Стоит заметить, что функция as_view() как раз возвращает указатель на dispatch(), что делает ясной аналогию с function-based views — в своем минималистичном варианте класс View — класс, содержащий всего одну функцию, которую и вызывает контроллер из URLCONF.

Класс View умеет вызывать свои фунции get(), post() и т.п. в зависимости от типа запроса, передавая request туда.

Пример

Пример простой реализации «вьюхи» в виде класса можно посмотреть, например, здесь. Ниже приведен сложный пример — моя переделка примера из документации — гораздо более полно иллюстрирующий удобство написания «вьюх» в виде классов.

Задача

Проект требует, чтобы любые данные, запрашиваемые клиентом, могли быть возвращены как в виде обычной HTML-страницы, так и в виде JSON-объекта — в зависимости от GET-параметра запроса.

Решение

Нужно написать общий класс «вьюхи», умеющий представлять ответ в двух видах, и от него наследовать все последующие «вьюхи» в проекте.

В django реализован TemplateResponseMixin, функция render_to_response() которого умеет рендерить указанный в template_name шаблон с переданным ей в качестве параметра контекстом.

Напишем свою примесь, которая будет вместо HTML возвращать JSON:

class JsonResponseMixin(object):
    def render_to_reponse(self, context):
        return http.HttpResponse(self.convert_context_to_json(context),
                                 content_type='application/json')

    def convert_context_to_json(self, context, extract_from_queryset=None):
        pass

Функцию конвертации контекста в JSON нужно писать уже понимая, что этот контекст из себя представляет, поэтому она не реализована.

Теперь напишем класс, который будет уметь возвращать и HTML, и JSON:

class MixedView(View, JsonResponseMixin, TemplateResponseMixin):
    def get_context(self, request):
        pass
    
    def get(self, request, *args, **kwargs):
        context = self.get_context(request)
        if request.GET.get('format', 'html') == 'json' or self.template_name is None:
            return JsonResponseMixin.render_to_reponse(self, context)
        else:
            return TemplateResponseMixin.render_to_response(self, context)     

Функция get переопределяет ту, что объявлена во View. В зависимости от GET-параметра, контекст отдается на рендеринг в одну из двух примесей, и возвращает JSON или HTML. В первом случае понадобится функция, определяющая перевод данного контекста в json. Во втором случае понадобится название шаблона, в котором этот контекст рендерить. Любая «вьюха»-наследник этой, должна иметь имплементации двух методов: get_context(request) — формирующего контекст, и convert_context_to_json(context) — переводящего его в JSON, и определенный template_name.

Реализация конечного view могла быть, например, такой:

class PublisherView(MixedView):
    def get_context(self, request):
        context = dict()
        context['publishers'] = Publisher.objects.all()
        return context

    template_name = 'publisher_list.html'

    def convert_context_to_json(self, context):
        json_context = dict()
        json_context['publisher_names'] = [p.name for p in context['publishers']]
        return json.dumps(json_context, encoding='utf-8', ensure_ascii=False)

Заключение

В этой статье я постарался прояснить то, чего мне нехватало в документации Django — идеи, стоящие за class-based views, и способ их использования. Надеюсь, практика такого повсеместного использования generic views и их последующего расширения в тех случаях, когда это необходимо, покажется кому-то полезной.

Спасибо за внимание, буду рад любой критике.