В этом случае любой кшольник-кулхацкер, запустивший сканер поиска ошибок, просто засыпет спамом :-) А если отчёты будут отправляться синхронно, ещё и отказ в обслуживании вызовет
500-ка это внутренняя ошибка сервера. Ключевое слово — внутренняя. То есть если БД упала, например, или место на диске закончилось. Как-то нехорошо, когда внутренняя ошибка провоцируется внешним воздействием.
Декоратором render_to вообще пользоваться моветон, на мой взгляд. Ладно бы жили в каменные времена версии 1.2, когда это было вынужденной мерой: тогда шорткаты были длиннее собственно функций, на которые ссылались.
Начиная с 1.3 есть django.shortcuts.render. А в 1.2, кстати, можно было импортировать direct_to_template as render. Получалось вполне себе универсально.
Я показал лишь пример LoginRequiredMixin. Разумеется, можно сделать более общий микшин UserPassesTestMixin и организовать его по образу и подобию аналогичного декоратора.
class LoginRequiredMixin(object):
@ method_decorator(login_required) # пробел после собачки надо убрать.
def dispatch(self, request, *args, **kwargs):
if self.test():
return super(LoginRequiredMixin, self).dispatch(request, *args, **kwargs)
else:
return self.test_failed()
def test_failed(self):
"Response в случае ошибки"
def test(self):
return True
И уже потом от него наследовать LoginRequired ;)
class LoginRequiredMixin(UserPassesTestMixin):
def test(self):
return self.request.user.is_authenticated()
class LoginRequiredMixin(object):
@ method_decorator(login_required) # пробел после собачки надо убрать.
def dispatch(self, request, *args, **kwargs):
return super(LoginRequiredMixin, self).dispatch(request, *args, **kwargs)
class PostDetailView(LoginRequiredMixin, DetailView):
model = Post
get_object_or_404 — это как get_object() в DetailView. Что такое get_model не очень из контекста ясно, но наверняка в List/Detail не пригодится. А вместо json_response, я считаю, лучше пользовать микшин.
Уверен, что у большинства есть своя bulletproof-библиотека с полезными функциями. Но досадно, что народ с завидным упорством плодит всё новые и новые пакеты: django-annoying, django-extensions, handy. А ведь функциональность зачастую перекрывается. Тот же render_to или json_response не реализовывал только ленивый.
И вместе с тем, очень многие из этих библиотек словно из прошлого века. В смысле, заточены под старые версии Джанги.
За упрощение жизни: многие в повседневной жизни используют CBV. Для них катастрофически не хватает микшинов с функциональностью, аналогичной декораторам. Или абстрактных моделей, в которых уже добавлены какие-то полезные колонки, которые приходится каждый раз добавлять руками (типа date_created).
По-моему, ошибка (очевидная) тут прямо в заголовке. Ну или в постановке задачи, если хотите. Как так — Django своими руками, для чего? Flask (джангоподобный фреймворк, который не накладывает ограничений на применяемые батарейки) существует давно и успешно.
Ни одного камня в его сторону не полетело, а ведь в рамках статьи явственно видна попытка сделать то же самое. Вот и получается, что это всего лишь попытка исправить пресловутый фатальный недостаток.
Недостаточный контроль за инвалидацией: можно инвалидировать объект, можно инвалидировать все объекты модели, больше ничего.
Все объекты кверисета. Со всеми его фильтрами. Что ещё нужно-то? :-)
Плюс, инвалидация только через удаление записи в кэше, что не всегда является лучшим решением (о чем я пишу в посте).
По-моему, Вы как раз и пишете, что обновлять данные в кеше не стоит, т.к. операция неатомарная. И таки да, это правильно.
Думаю, что пример с непосредственным вызовом операций типа incr и decr настолько частный случай (явное управление кешем с явно заданным бэкендом) не может рассматриваться как общий случай, который готовые решения покрывают. Я бы не стал эту претензию предъявлять ни к одному из generic-приложений. Случай не тот.
Хабраюзер Suor когда-то анонсировал свою разработку — django-cacheops. В качестве хранилища используется только redis. Если этот факт не смущает, то, думаю, пост можно считать закрытым :-)
Сравнивать pjax и backbone слегка некорректно. Первый — обёртка над браузерным History API. Второй — полноценный MVC-фреймворк. Да, в нём есть роутер, но использовать всю эту машинерию только ради аяксовых страничек… неразумно.
С другой стороны, если Вам нужен полноценный REST API, то и аяксовая навигация как таковая не нужна =)
По поводу аякса: кажется, можно было использовать django-pjax от Jacob Kaplan-Moss. Оно вроде бы делает ровно то же самое, но всё-таки велосипедом меньше :-)
По поводу виджетов и форм: мне кажется, что нет ничего страшного в том, чтобы задавать data-параметр в питоне: это всё-таки информация, а не её представление. Твик виджетов несколько усложнил для восприятия шаблоны. Или, как вариант, есть хорошее приложение для улучшения форм — django-floppyforms. Оно как раз реализует виджеты именно на шаблонах. Ну и, конечно, из коробки идёт несколько полезных HTML5-виджетов.
Для менюшек и прочего кеширование использовать, разумеется, можно (хоть и непонятно зачем: страницы-то целиком в запоминаются в мемкеше и при их вызове к джанге даже обращения нет). Но ради такой мелочи можно и locmem использовать.
render_toвообще пользоваться моветон, на мой взгляд. Ладно бы жили в каменные времена версии 1.2, когда это было вынужденной мерой: тогда шорткаты были длиннее собственно функций, на которые ссылались.Начиная с 1.3 есть
django.shortcuts.render. А в 1.2, кстати, можно было импортироватьdirect_to_template as render. Получалось вполне себе универсально.LoginRequiredMixin. Разумеется, можно сделать более общий микшин UserPassesTestMixin и организовать его по образу и подобию аналогичного декоратора.И уже потом от него наследовать LoginRequired ;)
Главное — вовремя остановиться =)
pkк целому (черезint</code). У неё это, разумеется, не получится.Впрочем, удаления тут не произойдёт. Будет некрасивая «пятисотка», но да, это плохо. Согласен.
ajax.catch(Post.DoesNotExist)Однако глаз коробит, согласен.
get_object_or_404 — это как get_object() в DetailView. Что такое get_model не очень из контекста ясно, но наверняка в List/Detail не пригодится. А вместо json_response, я считаю, лучше пользовать микшин.
render_toилиjson_responseне реализовывал только ленивый.И вместе с тем, очень многие из этих библиотек словно из прошлого века. В смысле, заточены под старые версии Джанги.
За упрощение жизни: многие в повседневной жизни используют CBV. Для них катастрофически не хватает микшинов с функциональностью, аналогичной декораторам. Или абстрактных моделей, в которых уже добавлены какие-то полезные колонки, которые приходится каждый раз добавлять руками (типа
date_created).Ни одного камня в его сторону не полетело, а ведь в рамках статьи явственно видна попытка сделать то же самое. Вот и получается, что это всего лишь попытка исправить пресловутый фатальный недостаток.
Все объекты кверисета. Со всеми его фильтрами. Что ещё нужно-то? :-)
По-моему, Вы как раз и пишете, что обновлять данные в кеше не стоит, т.к. операция неатомарная. И таки да, это правильно.
Думаю, что пример с непосредственным вызовом операций типа incr и decr настолько частный случай (явное управление кешем с явно заданным бэкендом) не может рассматриваться как общий случай, который готовые решения покрывают. Я бы не стал эту претензию предъявлять ни к одному из generic-приложений. Случай не тот.
С другой стороны, если Вам нужен полноценный REST API, то и аяксовая навигация как таковая не нужна =)
Ну и пару вопросов, как водится.
По поводу аякса: кажется, можно было использовать django-pjax от Jacob Kaplan-Moss. Оно вроде бы делает ровно то же самое, но всё-таки велосипедом меньше :-)
По поводу виджетов и форм: мне кажется, что нет ничего страшного в том, чтобы задавать data-параметр в питоне: это всё-таки информация, а не её представление. Твик виджетов несколько усложнил для восприятия шаблоны. Или, как вариант, есть хорошее приложение для улучшения форм — django-floppyforms. Оно как раз реализует виджеты именно на шаблонах. Ну и, конечно, из коробки идёт несколько полезных HTML5-виджетов.
Для менюшек и прочего кеширование использовать, разумеется, можно (хоть и непонятно зачем: страницы-то целиком в запоминаются в мемкеше и при их вызове к джанге даже обращения нет). Но ради такой мелочи можно и locmem использовать.