Comments 13
Это нормально, что в наследнике
DetailView метод get_queryset() возвращает объект модели, а не собственно кверисет? 
Нет, это моя оплошность) Поправил, хотя понял, что все равно пример немного не корректный.
В PrivatePostList не нужно передавать model и определять queryset одновременно. В данном случае достаточно было бы
Лучшим примером использования get_queryset был бы вывод постов текущего пользователя:
Еще не очень хорошая идея определять авторизованность пользователя в get_object. Для этого все-таки есть dispatch.
class PrivatePostList(DetailView):
queryset = Post.objects.filter(is_private=True, is_deleted=False)Лучшим примером использования get_queryset был бы вывод постов текущего пользователя:
def get_queryset(self):
return Post.objects.filter(author=self.request.user)Еще не очень хорошая идея определять авторизованность пользователя в get_object. Для этого все-таки есть dispatch.
Насчет метода dispatch у нас было обсуждение в первой части статьи, где пришли к выводу, что тревожить точку входа лишний раз не стоит. Да, есть некоторая неоднозначность с CBV на данный момент, нужно время, чтобы все пришло к единым стандартам, но на мой взгляд достаточно, чтобы метод делал то, что должен. То есть в данном случае метод get_object должен возвращать объект. С удовольствием бы почитал информацию по плюсам и минусам различных подходов.
Я только начинаю в этом разбираться. У меня несколько вопросов общего характера.
В документации написано, что «Class-based generic views» предназначены для большинства простых монотонных задач: редирект, рендер темплейта, вывод списка полей одного объекта и т.д. То есть конкретно для своих задач, я смогу собрать нужную «вьюшку» используя разные mixin'ы и наследуя базовые классы. Но! Вот я смотрю пример человечка, работавшего в «Яндексе», да и в документации подобные примеры есть.
Мне кажется, что несовсем изящно выглядят переопределения функций get_queryset и get_context_data где внутри функции описаны обращения к конкретным моделям. Мне кажется, конкретные модели и запросы нужно передавать в качестве аргументов в URLconf, что тоже не очень красиво.
Поэтому мне кажется, что «вьюшки» в виде фнкции для ряда многих задач, таких как собрать из нескольких моделей контекст и отправить в темплейт, могут быть решены наиболее удачно старым дедовским способом — функциями. Разве их убирать будут в следующих версиях? Или это касается только generic views?
В документации написано, что «Class-based generic views» предназначены для большинства простых монотонных задач: редирект, рендер темплейта, вывод списка полей одного объекта и т.д. То есть конкретно для своих задач, я смогу собрать нужную «вьюшку» используя разные mixin'ы и наследуя базовые классы. Но! Вот я смотрю пример человечка, работавшего в «Яндексе», да и в документации подобные примеры есть.
Мне кажется, что несовсем изящно выглядят переопределения функций get_queryset и get_context_data где внутри функции описаны обращения к конкретным моделям. Мне кажется, конкретные модели и запросы нужно передавать в качестве аргументов в URLconf, что тоже не очень красиво.
Поэтому мне кажется, что «вьюшки» в виде фнкции для ряда многих задач, таких как собрать из нескольких моделей контекст и отправить в темплейт, могут быть решены наиболее удачно старым дедовским способом — функциями. Разве их убирать будут в следующих версиях? Или это касается только generic views?
На данный момент касается лишь function based generic views, хотя в будущем ситуация может и поменяться и нужно быть готовым.
Насчет переопределения методов отображения — большинство примеров «синтетические», сделаны лишь чтобы показать возможность их переопределения. Для типичных задач можно обойтись лишь парой строк, в идеальном варианте например так:
Этого уже достаточно, чтобы отобразить разбитый на страницы список объектов, при условии что мы не нуждаемся в дополнительных проверках.
Можно еще больше упростить и вызывать в нашем urlconf непосредственно класс ListView, передавая ему необходимую модель:
Да и опыт показал, что с помощью CBV вполне можно строить сложную логику отображений, причем меньшим количеством кода. Разумеется не стоит лепить классы там, где требуется очень простая логика, особенно если она не подразумевает необходимости повторного использования.
Насчет переопределения методов отображения — большинство примеров «синтетические», сделаны лишь чтобы показать возможность их переопределения. Для типичных задач можно обойтись лишь парой строк, в идеальном варианте например так:
class PostList(ListView):
model = Post
Этого уже достаточно, чтобы отобразить разбитый на страницы список объектов, при условии что мы не нуждаемся в дополнительных проверках.
Можно еще больше упростить и вызывать в нашем urlconf непосредственно класс ListView, передавая ему необходимую модель:
url(r'^posts/page(?P<pk>\d+)/$', ListView.as_view(model=Post)),Да и опыт показал, что с помощью CBV вполне можно строить сложную логику отображений, причем меньшим количеством кода. Разумеется не стоит лепить классы там, где требуется очень простая логика, особенно если она не подразумевает необходимости повторного использования.
Да в том-то и дело, что одна из очень распространенных задач — проверить slug и отфильтровать по нему таблицу и связанные с ней другие. А для этого нужно перкрывать метод get_queryset. Ну вобщем я разобрался, там просто можно не указывать эти модели явно, а оставить в качестве свойств класса: модель (уже реализована в ListView) и модель, которая будет фильтроваться. Спасибо за статью.
> На данный момент касается лишь function based generic views, хотя в будущем ситуация может и поменяться и нужно быть готовым.
Никто вьюхи на функциях deprecated не объявит, не переживайте.
Никто вьюхи на функциях deprecated не объявит, не переживайте.
Я после этих постов размышлял наж этими квинтэссенциями, еще раз перечитывал документацию по CBGV, и пришел к выводу, что для сложной архитектуры и плюшек ООП с абстракцией и наследованием можно вообще все это самому обернуть в класс, а эту вью-функцию сделать статическим методом или методом класса, которая будет вызывать другие функции в классе. А CBGV использовать или по их прямому назначению, или только с небольшими изменениями.
я вот не могу понять django.views.generic.list_detail. object_detail, object_list, etc…
они deprecated или нет?
они deprecated или нет?
Судя по первым строкам в документации все же да.
Думаю на этом этапе можно закончить рассмотрение функциональности DetailView, если я все же пропустил что-то важное, то прошу сообщить и я дополню статью.
думаю имелось ввиду ListVew
Пс: Спасибо автору за статью, очень доходиво
В url указан класс PostDetail, тогда как сам класс называется PostView. Стоит поправить опечатку!
Sign up to leave a comment.
Немного подробностей про Class Based Views, ч.3