В чем преимущество представлений на основе классов? - PullRequest
Новая
       2

В чем преимущество представлений на основе классов?

79 голосов
/ 06 декабря 2010

Сегодня я прочитал, что Django 1.3 alpha поставляется, и самой популярной новой функцией является введение представлений на основе классов .
Я прочитал соответствующую документацию , но мне трудно увидеть большое преимущество ™ , которое я мог бы получить, используя их, поэтому я прошу здесь некоторую помощь в их понимании .
Давайте возьмем расширенный пример из документации.

urls.py 

from books.views import PublisherBookListView

urlpatterns = patterns('',
    (r'^books/(\w+)/$', PublisherBookListView.as_view()),
)

views.py 

from django.shortcuts import get_object_or_404
from django.views.generic import ListView
from books.models import Book, Publisher

class PublisherBookListView(ListView):

    context_object_name = "book_list"
    template_name = "books/books_by_publisher.html",

    def get_queryset(self):
        self.publisher = get_object_or_404(Publisher, name__iexact=self.args[0])
        return Book.objects.filter(publisher=self.publisher)

    def get_context_data(self, **kwargs):
        # Call the base implementation first to get a context
        context = super(PublisherBookListView, self).get_context_data(**kwargs)
        # Add in the publisher
        context['publisher'] = self.publisher
        return context

А теперь давайте сравним его с решением «обычные старые взгляды», которое я сделал за 5 минут для этого вопроса (прошу прощения за любую ошибку, которую вы можете найти в нем).

urls.py 

urlpatterns = patterns('books.views',
    url(r'^books/(\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

views.py 

from django.shortcuts import get_object_or_404
from books.models import Book, Publisher

def publisher_books_list(request, publisher_name):
    publisher = get_object_or_404(Publisher, name__iexact=publisher_name)
    book_list = Book.objects.filter(publisher=publisher)

    return render_to_response('books/books_by_publisher.html', {
        "book_list": book_list,
        "publisher": publisher,
    }, context_instance=RequestContext(request))

Вторая версия для меня выглядит:

  • Эквивалент по функциональности
  • намного более читабельно (self.args[0]? Ужасно!)
  • 1035 * Короче *
  • Не менее DRY-совместимый

Есть что-то большое, что мне не хватает? Почему я должен их использовать? Они есть в документации? Если так, то что было бы идеальным вариантом использования? mixins это полезно?

Заранее спасибо всем, кто вносит свой вклад!

P.S. для тех, кто может задаться вопросом, я никогда не был в восторге от общих представлений: как только мне понадобились некоторые расширенные функциональные возможности, они стали не короче, чем обычные представления.

Ответы [ 5 ]

48 голосов
/ 07 декабря 2010

Вы можете создать подкласс класса и улучшить методы, такие как get_context_data для конкретных случаев, и оставить все как есть.Вы не можете сделать это с помощью функций.

Например, вам может потребоваться создать новое представление, которое выполняет все предыдущие действия, но вам нужно включить в контекст дополнительную переменную.Создайте подкласс исходного представления и переопределите метод get_context_data.

Кроме того, разделение шагов, необходимых для визуализации шаблона на отдельные методы, способствует более четкому коду - чем меньше будет выполнено метода, тем легче его понять.С обычными функциями просмотра все это выгружается в один блок обработки.

16 голосов
/ 21 января 2011

Если self.args[0] беспокоит вас, альтернатива: 

urlpatterns = patterns('books.views',
    url(r'^books/(?P<slug>\w+)/$', 'publisher_books_list', name="publisher_books_list"),
)

Тогда вы можете использовать self.kwargs['slug'] вместо этого, делая его немного более читабельным.

10 голосов
/ 25 марта 2011

Ваш пример функции и класса не совпадают по функциям.

Версия на основе классов обеспечивает бесплатное разбиение на страницы и запрещает использование других HTTP-глаголов, кроме GET.

Если вы хотите добавить это к своей функции, это будет намного дольше.

Но на самом деле все сложнее.

4 голосов
/ 06 декабря 2010

Это первый раз, когда я слышу об этом - и мне это нравится.

Честно говоря, я вижу здесь преимущество в том, что оно делает взгляды более совместимыми с Джанго в целом.Модели - это классы, и я всегда чувствовал, что взгляды тоже должны быть.Я знаю, что не все, но виды и модели - это два широко используемых типа .

Что касается технического преимущества?Ну, в Python все это класс ( или объект ?) - так есть ли разница?Разве это не 99% синтаксический сахар?

1 голос
/ 19 марта 2015

Один из способов думать о представлениях, основанных на классе, состоит в том, что они похожи на администратора Django с отключенными тренировочными колесами и, следовательно, более гибкими (но более сложными для понимания).

Например, отображение списка в администраторе явно основано на универсальном ListView.В простейшем представлении списка вы можете определить только модель или набор запросов.

class MyExampleView(ListView);
    model = ExampleModel

Вам потребуется указать собственный шаблон, но он будет в основном таким же, как и самый базовый ModelAdmin.Атрибут list_display в администраторе модели сообщит ему, какие поля отображать, тогда как в ListView вы сделаете это в шаблоне.

class SpeciesAdmin(admin.ModelAdmin):
    list_display = ['name']
admin.site.register(ExampleModel , ExampleModelAdmin)

С администратором у вас есть параметр 

list_per_page = 100

, который определяет, сколько объектов на странице.Представление списка имеет 

paginate_by = 100

, который достигает того же самого.Точно так же, если вы внимательно изучите настройку администратора, вы увидите много совпадений.

Этот сайт должен дать вам лучшее представление о том, что они делают.

http://ccbv.co.uk/

...