Pull to refresh

Comments 10

Спасибо, заполнил пробел в этом вопросе :)
а модуль nginx для определения мобильной версии у вас выложен в опенсорс?
Определение типа устройства — лишь малая часть функционала этого модуля, а сам модуль сильно заточен под наши проекты.
Заключение надо ставить первым абзацем, как по мне — правильный дисклеймер. Резолвить преходы — такой геморрой, бррр.
Насколько все стало краше, когда перешел на адаптивную верстку. Кстати, это потребовало значительно облегчить дизайн и, следовательно, шаблоны/код.
p.s все еще пишете def foo(request)? Тогда мы идем к вам!
class based views удобны, но это не замена, а альтернатива, я использую оба способа.
class based view я обычно использую, когда код вьюхи становится большой, уднобно куски вынести в отдельные методы. Или когда несколько вьюх содежат общую логику и удобно сделать общий класс и понаследоваться. Когда код вьюхи короткий и нужно обрабатывать только один HTTP метод — функции гораздо удобнее.
Ну автор таки написал декоратор, который мог идти в родительском методе класса и обновление context словаря (canonical, alternate) тоже скорее всего можно добавить в get_context_data.
Мне кажется класс-вью это новый django-guideline. По крайней мере, многие батарейки, которые я использую переходят на views.generic просто так, заранее.
Это я так. Никто, конечно, никому ничего не запрещает и не указывает.
Это да, мне декоратор в этом месте тоже показался странным решением. Я просто подумал, что вы вообще против вьюх-функций.
CBV вовсю используются на проекте, в тексте есть примеры роутов с ними.
Что касается контроллера с декоратором, согласен, можно было реализовать с классовой вьюхой на основе RedirectView.
А постоянные конференции в мейле на мысль не навевали?
Sign up to leave a comment.