Ну если кто-нибудь не возьмется написать, то возможно попробую собрать список используемых миксинов. Хотя тут все уже зависит от конкретных задач и универсальных рецептов нет.
К сожалению фотографии во время прохождения военной службы сделать не было возможности, поэтому сохранилась лишь фотография со сборного пункта (Казань, май 2005 года). Служил в Свердловской области, п.Елань, может сослуживцев найду на хабре)
Способ, указанный в апдейте статьи, работает, спасибо) Просто после открытия ссылки надо немного подождать, страница будет грузится минуты 3, а потом еще столько же после ввода адреса эл.почты. Если придут еще купоны, то постараюсь раздать в личку.
Ну в принципе я указал, что все примеры синтетические. В любом случае перед сохранением объекта потребуются дополнительные проверки или необходимо проставить внешние ключи, о чем вы уже упомянули. Не хотелось просто перегружать примеры логикой, которая не связанна непосредственно с ними. Спасибо за пример, добавлю и его как демонстрация более правильного решения данной задачи.
И ещё: не надоело в каждой вьюхе писать что-то такое?
Как я выше упомянул — примеры надуманные и не связанные между собой. Это не часть какого-то проекта, я просто упомянул о существовании данной возможности
Разумеется если вам потребуются соответсвующие проверки на наличие авторизации у пользователей или соответствующих прав, то вы можете сделать это используя декораторы для метода dispatch или добавить свою логику проверки:
Спасибо еще раз за объективную критику, на мой взгляд многие из ваших комментариев были полезнее самой статьи)
Насчет метода dispatch у нас было обсуждение в первой части статьи, где пришли к выводу, что тревожить точку входа лишний раз не стоит. Да, есть некоторая неоднозначность с CBV на данный момент, нужно время, чтобы все пришло к единым стандартам, но на мой взгляд достаточно, чтобы метод делал то, что должен. То есть в данном случае метод get_object должен возвращать объект. С удовольствием бы почитал информацию по плюсам и минусам различных подходов.
На данный момент касается лишь function based generic views, хотя в будущем ситуация может и поменяться и нужно быть готовым.
Насчет переопределения методов отображения — большинство примеров «синтетические», сделаны лишь чтобы показать возможность их переопределения. Для типичных задач можно обойтись лишь парой строк, в идеальном варианте например так:
class PostList(ListView):
model = Post
Этого уже достаточно, чтобы отобразить разбитый на страницы список объектов, при условии что мы не нуждаемся в дополнительных проверках.
Можно еще больше упростить и вызывать в нашем urlconf непосредственно класс ListView, передавая ему необходимую модель:
Да и опыт показал, что с помощью CBV вполне можно строить сложную логику отображений, причем меньшим количеством кода. Разумеется не стоит лепить классы там, где требуется очень простая логика, особенно если она не подразумевает необходимости повторного использования.
И снова от меня тысяча благодарностей :) Действительно, я даже не удосужился посмотреть в исходный код. Радует, что разработчики django предусмотрели в списке объектов пагинацию «из коробки». Однако огорчает обилие лишних переменных. Все эти object_list и page_obj стоило, наверное, как-то собрать в 1 объект, чтобы было проще вызывать в шаблоне.
UPD. Обновил пример в статье (спасибо пользователю marazmiki). А также выложил тестовый проект, включающий данный пример. Не забудьте отредактировать файл settings.py под свои нужды. Проект можно найти здесь. Если вы обнаружите какие-либо ошибки или недоработки, то прошу сообщить.
Насчет dispatch и get_queryset, в принципе, полностью согласен. Но пример не совсем удачный скорее не потому, что его можно сделать меньше, а потому, что он охватывает всего пару методов, имеющихся в CBV. В идеале, для лучшего восприятия материала, надо было показать работу и с остальными методами. Вот только не знаю как это лучше реализовать, чтобы все и сразу. А делать для этого отдельную статью было бы излишне с моей стороны.
Спасибо вам за конструктивные комментарии. Как я уже написал в статье — информации по CBV и правильным практикам их применения очень мало. Большинство их сходится лишь к холиварам на темы плохо это или хорошо. Поэтому все приходится изучать путем проб, ошибок и просмотра исходного кода. Пример в статье перепишу с учетом вашего комментария.
Думаю то же, что и использование в других местах. Это не совсем преимущество, просто другой угол зрения, но для меня более удобным является возможность сделать базовый класс, определить функциональность, которая требуется в других отображениях. Затем данный класс можно наследовать другими отображениями как «примеси», используя на порядок меньше кода. Множественное наследование позволяет использовать несколько «примесей» для одного отображения, главное не забыть проконтролировать их порядок применения и конфликты.
Ну в принципе я указал, что все примеры синтетические. В любом случае перед сохранением объекта потребуются дополнительные проверки или необходимо проставить внешние ключи, о чем вы уже упомянули. Не хотелось просто перегружать примеры логикой, которая не связанна непосредственно с ними. Спасибо за пример, добавлю и его как демонстрация более правильного решения данной задачи.
Как я выше упомянул — примеры надуманные и не связанные между собой. Это не часть какого-то проекта, я просто упомянул о существовании данной возможности
Спасибо еще раз за объективную критику, на мой взгляд многие из ваших комментариев были полезнее самой статьи)
Насчет переопределения методов отображения — большинство примеров «синтетические», сделаны лишь чтобы показать возможность их переопределения. Для типичных задач можно обойтись лишь парой строк, в идеальном варианте например так:
Этого уже достаточно, чтобы отобразить разбитый на страницы список объектов, при условии что мы не нуждаемся в дополнительных проверках.
Можно еще больше упростить и вызывать в нашем urlconf непосредственно класс ListView, передавая ему необходимую модель:
Да и опыт показал, что с помощью CBV вполне можно строить сложную логику отображений, причем меньшим количеством кода. Разумеется не стоит лепить классы там, где требуется очень простая логика, особенно если она не подразумевает необходимости повторного использования.
Спасибо вам за конструктивные комментарии. Как я уже написал в статье — информации по CBV и правильным практикам их применения очень мало. Большинство их сходится лишь к холиварам на темы плохо это или хорошо. Поэтому все приходится изучать путем проб, ошибок и просмотра исходного кода. Пример в статье перепишу с учетом вашего комментария.