Comments 29
Дождаться бы еще этого релиза. С декабря волынку тянут.
Я сделал параллельно перевод чейнджлога.
Кстати, в примечаниях к релизу стоит обратить внимение на вещи, ломающие обратную совместимость кода, например, проверка CSRF-токенов и для ajax-видов. Из-за этого аяксовые формы без токена не будут обрабатываться. Это сделано для предотвращения особо хитрой CSRF-атаки.
Кстати, в примечаниях к релизу стоит обратить внимение на вещи, ломающие обратную совместимость кода, например, проверка CSRF-токенов и для ajax-видов. Из-за этого аяксовые формы без токена не будут обрабатываться. Это сделано для предотвращения особо хитрой CSRF-атаки.
Наконец-то для ForeignKey сделали выбор поведения при удалении. TemplateResponse тоже рулит, код чище будет.
>Вьюхи, основанные на классах.
Весьма интересно.
К примеру, я сейчас вьюхи оборачиваю в спец декораторы которые парсят get и post запросы, таким образом улучшается логика и наглядность приложения (пропадают нагромождения stuff-блоков кода).
@login_required() #это стандартный
@handle_get #а эти два кастомные
@details_post
def details(request, BlahInstance):
pass
Вьюхи на классах на мой взгляд будут намного гибче по сравнению с вышеприведённым примером. Но точно пока ничего сказать не могу, так как RC еще не смотрел. Интересный обзор, спасибо.
Весьма интересно.
К примеру, я сейчас вьюхи оборачиваю в спец декораторы которые парсят get и post запросы, таким образом улучшается логика и наглядность приложения (пропадают нагромождения stuff-блоков кода).
@login_required() #это стандартный
@handle_get #а эти два кастомные
@details_post
def details(request, BlahInstance):
pass
Вьюхи на классах на мой взгляд будут намного гибче по сравнению с вышеприведённым примером. Но точно пока ничего сказать не могу, так как RC еще не смотрел. Интересный обзор, спасибо.
Наконец-то RequestContext можно будет удобно использовать из коробки! Хороший релиз, пойду обновляться.
Очень надеюсь, что это один из шагов к RESTификации джанги. Ибо для создания полноценных api сегодня приходится писать жуткие костыли.
Вьюхи, основанные на классах
Очень надеюсь, что это один из шагов к RESTификации джанги. Ибо для создания полноценных api сегодня приходится писать жуткие костыли.
Какие такие костыли?
В любом случае, на новых CBV есть django-rest-framework.org/ (но все-таки CBV меня немного пугают Mixin'ами своими), мы django-tastypie используем для API, удачная штука.
В любом случае, на новых CBV есть django-rest-framework.org/ (но все-таки CBV меня немного пугают Mixin'ами своими), мы django-tastypie используем для API, удачная штука.
Django rest framework использую уже больше месяца. Не особо удобен при большом количестве моделей и полей с моделями — приходится для каждой описывать разрешенные поля и запросы по многу раз etc. Сейчас для таких целей в каждой модели просто делаю кортеж allowed_fields — явный костыль. Еще он не сильно гибкий, возможностей мало, ведь разработка началась недавно. Хотя по сравнению с piston это рай.
Да и бывает так, что в большинстве api resources просто дублируют вьюхи. Этого можно было бы избежать, если джанга умела REST из коробки, как рельсы, торнадо и многие современные веб-фреймворки.
Tastypie вскопну, спасибо.
Да и бывает так, что в большинстве api resources просто дублируют вьюхи. Этого можно было бы избежать, если джанга умела REST из коробки, как рельсы, торнадо и многие современные веб-фреймворки.
Tastypie вскопну, спасибо.
Под REST, по-моему, каждый разработчик что-то свое понимает) У кого-то это роутинг согласно методам http, у кого-то — соглашения о том, как иерархию url'ов строить, у кого-то главное — ссылки на ресурсы через uri, а не по первичным ключам, у кого-то — что о ресурсах, предоставляемых api, можно узнать, спросив об этом api.
Модуль для статичных файлов особенно радует. Его и для продакшена можно полноценно использовать?
Да, конечно. При разработке статика сама подхватывается, если подключить в urls.py проекта нужную строку, а для продакшна есть management-команда, которая статику собирает в одну папку (или куда угодно), а туда уже можно натравить веб-сервер.
Пока его можно установить в качестве приложения, только вот компрессора работающего с ним я не видел.
И да, автосбор статики — вещь!
И да, автосбор статики — вещь!
Как минимум github.com/miracle2k/webassets и github.com/jezdez/django_compressor работают, если брать с гитхаба, а не с pypi.
Да, но там нужно вручную бандлы формировать, что не есть хорошо.
А что плохого? Все js-файлы в 1 сжимать (например, jquery + свой код одновременно) будет неправильно, т.к. при изменении какой-нибудь мелочи в коде приложения пользователям нужно будет и jquery тот же повторно скачивать. Или, например, зачем пользователяс фронтенда статика от джанговской админки. Лучше уж контроль над этим иметь по-моему.
Ну я же не говорил, что нужно обязательно ТАК это делать. Тем более джанга могла бы сама из респонса все вытаскивать и делать это нормально.
А как нужно делать? Я правда не понял) Если есть какая-то идея, которую можно формализовать и в виде кода реализовать, то можно ведь это сделать.
Постараюсь объяснить идею, как я думал оно должно было бы работать.
Staticfiles ищет всю статику, которая есть в используемых приложениях (пока это не всегда работает, но это из-за свежести стандарта). Все это попадает в STATIC_ROOT.
Затем «мидлварь» берет Responce, ищет там все ссылки на статику (а они по умолчанию относительно, по стандартам фреймворка). Затем все это дело хешируется, и жмется в файл с соответствующим именем.
Отдельно хочется сказать только про разный набор запрашиваемых файлов, тут нужно просто подумать как хеш сделать, что-бы он при отсутствии нескольких файлов выдавал нужный файл.
Минус один — небольшая потеря в производительности…
Staticfiles ищет всю статику, которая есть в используемых приложениях (пока это не всегда работает, но это из-за свежести стандарта). Все это попадает в STATIC_ROOT.
Затем «мидлварь» берет Responce, ищет там все ссылки на статику (а они по умолчанию относительно, по стандартам фреймворка). Затем все это дело хешируется, и жмется в файл с соответствующим именем.
Отдельно хочется сказать только про разный набор запрашиваемых файлов, тут нужно просто подумать как хеш сделать, что-бы он при отсутствии нескольких файлов выдавал нужный файл.
Минус один — небольшая потеря в производительности…
django_compresor это вроде бы и делает, только ссылки на статику в шаблоне нужно явно тегом окружить (можно все сразу). Но это не обязательно плюс — в webassets писать кода меньше в результате. Или я опять не понял?
Вот, примерно то, что я предлагал: github.com/citylive/django-template-preprocessor/blob/master/src/template_preprocessor/README.txt
В webassets есть поддержка glob'ов, к тому же.
Не совсем понял, можете пояснить? Когда я его смотрел он мне статику отказывался от некоторых аппов находить (от тех которые были в виртуальном окружении).
С webassets все очень просто: в продакшне он сейчас жмет статику прямо из STATIC_ROOT, при разработке не жмет совсем. См. github.com/miracle2k/webassets/issues#issue/21.
А glob — это в смысле что можно файлы по одному не перечислять, а звездочки и вопросики использовать.
Если что-то не работает из этого — то, видимо, в баг-трекер лучше.
А glob — это в смысле что можно файлы по одному не перечислять, а звездочки и вопросики использовать.
Если что-то не работает из этого — то, видимо, в баг-трекер лучше.
Еще один шаг в сторону значительного улучшения фреймворка:) Трижды ура! Правда затянули ужас как, с другой стороны оно того стоило, столько классных улучшений, на сколько я помню гораздо больше чем в 1.2.
staticfiles, render и foreignkey явно не хватало. Пошел читать про остальное…
staticfiles, render и foreignkey явно не хватало. Пошел читать про остальное…
А /me вчера отрепортил баг и сегодня его уже пофиксили :-). code.djangoproject.com/changeset/15882
A roadmap for Django’s overall 2.x Python support, and eventual transition to Python 3.x, is currently being developed, and will be announced prior to the release of Django 1.3.
Пока они будут тянуть кота за яйца — выйдет 4 пайтон
Пока они будут тянуть кота за яйца — выйдет 4 пайтон
Прошу прощения за дезинформацию: вьюхи из django.contrib.admin не возвращают TemplateResponse, соответствующий тикет к релизу не закоммитили.
Sign up to leave a comment.
Что будет в django 1.3