А разве обычные вьюхи (не generic) стали deprecated? Я всегда почему то думал, что можно внутри своей вьюхи вызвать ListView.as_view и передать ей все те параметры как и раньше. Правда там получается какая то морока с extra_context (я так понял, что его теперь нельзя передать не наследуя), но зато если нужно расширить функциональность generic view и при этом оставить ее все же generic то cbv получаются более гибкими.
glader.livejournal.com
Есть подозрение, что как Джанго странно смотрится на микропроектрах, так и CBV странно смотрятся на микровьюхах. И большой профит будет для проектов с большими развесистыми вьюхами, выполняющими много вычислений. Их легче будет наследовать, изменяя только часть функционала.
Ivan Sagalaev
А разве обычные вьюхи (не generic) стали deprecated?
Нет, конечно. Я и написал в конце, что свои вьюхи делать классами смысла нет.
Правда там получается какая то морока с extracontext (я так понял, что его теперь нельзя передать не наследуя)
Да, это ещё одно неудобство, оно тоже сыграло свою роль :-)
но зато если нужно расширить функциональность generic view и при этом оставить ее все же generic то cbv получаются более гибкими.
Не более гибкими. Всё тоже самое всегда делали, оборачивая generic вьюхи в свои функции.
Андрей Богомолов
Не более гибкими. Всё тоже самое всегда делали, оборачивая generic вьюхи в свои функции.
Ну например вот такой случай: необходимо вычислить пару значений для переменных контекста на основе полученного объекта используя object_detail вьюху. Без использования cbv и переопределения метода get_context_data (где нужный объект уже получен из переданного queryset на основе pk или slug) я не представляю как это написать не нарушая DRY.
Ivan Sagalaev
необходимо вычислить пару значений для переменных контекста на основе полученного объекта используя object_detail вьюху. Без использования cbv и переопределения метода get_context_data (где нужный объект уже получен из переданного queryset на основе pk или slug) я не представляю как это написать не нарушая DRY.
Я и не спорю, что предыдущая реализация generic вьюх была ограниченной. Моя позиция в том, что для придания им гибкости не нужен был синтаксис классов. Конкретно описанную задачу можно было решить разными способами:
Научить вьюху получать не только queryset и id, из которого она выбирает объект, но и непосредственно объект. Тогда обёртка может выбрать объект сама. Это либо прямой вызов Model.objects.get(pk=1), либо можно было бы иметь утилитарную функцию get_object(queryset, id=None, slug=Non), хотя это уже overkill.
Воспользоваться TemplateResponse (появившимся тогда же, когда и CBV). Он впрямую предназначен для того, чтобы менять контекст, после работы вьюхи:
Комментарии: 6
А разве обычные вьюхи (не generic) стали deprecated? Я всегда почему то думал, что можно внутри своей вьюхи вызвать ListView.as_view и передать ей все те параметры как и раньше. Правда там получается какая то морока с extra_context (я так понял, что его теперь нельзя передать не наследуя), но зато если нужно расширить функциональность generic view и при этом оставить ее все же generic то cbv получаются более гибкими.
Есть подозрение, что как Джанго странно смотрится на микропроектрах, так и CBV странно смотрятся на микровьюхах. И большой профит будет для проектов с большими развесистыми вьюхами, выполняющими много вычислений. Их легче будет наследовать, изменяя только часть функционала.
Нет, конечно. Я и написал в конце, что свои вьюхи делать классами смысла нет.
Да, это ещё одно неудобство, оно тоже сыграло свою роль :-)
Не более гибкими. Всё тоже самое всегда делали, оборачивая generic вьюхи в свои функции.
Ну например вот такой случай: необходимо вычислить пару значений для переменных контекста на основе полученного объекта используя object_detail вьюху. Без использования cbv и переопределения метода get_context_data (где нужный объект уже получен из переданного queryset на основе pk или slug) я не представляю как это написать не нарушая DRY.
Я и не спорю, что предыдущая реализация generic вьюх была ограниченной. Моя позиция в том, что для придания им гибкости не нужен был синтаксис классов. Конкретно описанную задачу можно было решить разными способами:
Научить вьюху получать не только queryset и id, из которого она выбирает объект, но и непосредственно объект. Тогда обёртка может выбрать объект сама. Это либо прямой вызов
Model.objects.get(pk=1), либо можно было бы иметь утилитарную функциюget_object(queryset, id=None, slug=Non), хотя это уже overkill.Воспользоваться TemplateResponse (появившимся тогда же, когда и CBV). Он впрямую предназначен для того, чтобы менять контекст, после работы вьюхи:
Написал свои размышления на эту тему http://kimavr.name/blog/2011/9/2/7/ Получилось что-то вроде "почему я люблю class-based generic views" :-)