Comments 3
Очень спорная статья. В «заключении» автор немного поправился, сказав, что в каждом случае надо думать головой, тут он прав…
Но CBV, на мой взгляд, отличная идея. Лично мне очень удобно создать класс, подмешать пару mixins и получить поведение из уже готовых классов. В половине случаев этого хватает. Если не хватает — надо подумать — а не делаю ли я все слишком сложным?
Лапша из методов вместо классов (Flask?), на мой, опять же, взгляд — только запутывает. В классах даже по имени можно понять что это View, а функция может быть просто вспомогательной.
Смешно получилось про magic* функции — автор сначала возмущается тем, что неявно задаются имена шаблонов, а потом предлагает некие неявные магические функции.
Явный вызов super(), как мне кажется, это вообще must have. Иногда не нужно его вызывать, если все, что мне надо я генерирую в контекст сам. Иногда я подмешиваю что-то в контекст, полученный из super().get_context(), но иногда нужно выполнить какие-то действия до того, как передавать выполнение родителю. Именно это и удобно в Python — управляемый вызов методов родителя.
Про «хаки для прерывания наследования» — ну это уже нытье. Если слишком сложно получается вспоминать как все наследуется — ну возьми и не вызывай родительские функции, скопипасти в свой класс все сам. Не более грязно, но более явно хотя бы.
«Пишите свои базовые классы» — это вообще очевидно уже ко второму проекту на Django. Для каждого проекта он может быть своим, но тем не менее… И дает гибкость при наследовании.
В этом и сила CBV.
Но CBV, на мой взгляд, отличная идея. Лично мне очень удобно создать класс, подмешать пару mixins и получить поведение из уже готовых классов. В половине случаев этого хватает. Если не хватает — надо подумать — а не делаю ли я все слишком сложным?
Лапша из методов вместо классов (Flask?), на мой, опять же, взгляд — только запутывает. В классах даже по имени можно понять что это View, а функция может быть просто вспомогательной.
Смешно получилось про magic* функции — автор сначала возмущается тем, что неявно задаются имена шаблонов, а потом предлагает некие неявные магические функции.
Явный вызов super(), как мне кажется, это вообще must have. Иногда не нужно его вызывать, если все, что мне надо я генерирую в контекст сам. Иногда я подмешиваю что-то в контекст, полученный из super().get_context(), но иногда нужно выполнить какие-то действия до того, как передавать выполнение родителю. Именно это и удобно в Python — управляемый вызов методов родителя.
Про «хаки для прерывания наследования» — ну это уже нытье. Если слишком сложно получается вспоминать как все наследуется — ну возьми и не вызывай родительские функции, скопипасти в свой класс все сам. Не более грязно, но более явно хотя бы.
«Пишите свои базовые классы» — это вообще очевидно уже ко второму проекту на Django. Для каждого проекта он может быть своим, но тем не менее… И дает гибкость при наследовании.
В этом и сила CBV.
Насчет не явности магических функций — они такие же не явные, как и любая другая самописная функция. Только для просмотра и понимания их реализации не нужно лезть в исходники фреймворка, или знать о конкретных его умолчаниях. Хотя я вообще слабо представляю, зачем человек, не знающий таких базовых умолчаний полезет поддерживать или дебажить проект на джанге.
По поводу добавления контекста категорически согласен с автором. Весьма распространенная операция, и каждый раз пилить context = super(MyView, self).get_context_data() попросту утомительно.
Копипаста функций в свой класс — нарушение принципа DRY. Так же возникает вопрос, зачем тогда вообще CBV, если не для наследования?
У Вас с автором разный подход. Вы ищете, как сделать в рамках фреймворка, а он ищет, как сделать проще.
По поводу добавления контекста категорически согласен с автором. Весьма распространенная операция, и каждый раз пилить context = super(MyView, self).get_context_data() попросту утомительно.
Копипаста функций в свой класс — нарушение принципа DRY. Так же возникает вопрос, зачем тогда вообще CBV, если не для наследования?
У Вас с автором разный подход. Вы ищете, как сделать в рамках фреймворка, а он ищет, как сделать проще.
Python-way — явное лучше неявного.
Упрощая дальше, можно дойти до RubyOnRails (no offense!), где магия на каждом шагу и у вас голова пухнет от понимания того, сколько всего на самом деле может выполняться в приложении неявно кроме вашего кода.
Не поймите меня неправильно, я не настаиваю на том, чтобы все указывать явно, но золотая середина должна быть.
Любой способ, удобный в одном случае — может стать совершенно неудобным в другом.
Про спорный момент с контекстом: можно context сделать атрибутом объекта, как request, тогда он может автоматически заполняться родителем в определенный момент. И в любом месте self.context будет доступен уже полузаполненным — используйте.
Упрощая дальше, можно дойти до RubyOnRails (no offense!), где магия на каждом шагу и у вас голова пухнет от понимания того, сколько всего на самом деле может выполняться в приложении неявно кроме вашего кода.
Не поймите меня неправильно, я не настаиваю на том, чтобы все указывать явно, но золотая середина должна быть.
Любой способ, удобный в одном случае — может стать совершенно неудобным в другом.
Про спорный момент с контекстом: можно context сделать атрибутом объекта, как request, тогда он может автоматически заполняться родителем в определенный момент. И в любом месте self.context будет доступен уже полузаполненным — используйте.
Sign up to leave a comment.
Мой подход к Class Based Views