Одно из слабых мест джанго-админки — главная страница. Идея авто-группировки моделей по приложениям и вывод столбиком в одну колонку работает только на начальных этапах, дальше это становится просто неудобно — куча лишней информации и довольно сложные пути для того, чтобы добавить полезную. Ну, например, чтобы названия приложений писались русскими буквами — полностью перекрывать шаблон.

И тут на помощь приходит django-admin-tools. С этим приложением минут за 20 можно получить «приборную панель» с произвольной группировкой приложений/моделей, вкладками, любым числом колонок, различными блоками, которые каждый пользователь сможет расставить, как ему удобнее, скрывать и сворачивать по желанию, закладками, настраиваемым меню и удобным способом добавления во все это хозяйство всего, чего только можно придумать.

Вот так, например, сейчас выглядит админка к сайту НадоВместе:


(это только часть, вот скриншот целиком)

Разберемся поподробнее.

Статья описывает создание простейшей сокращалки ссылок, вроде bit.ly или goo.gl.

Практически для всех возможностей Django существуют способы модификации и расширения. Крайне редко может понадобиться переписывать существенную часть функционала Django только для того, чтобы изменить действие какого-то инструмента. Например, если вы хотите изменить внешний вид формы, вы можете отказаться от внешнего вида «по умолчанию» и создать собственное поле, или даже просто использовать собственный HTML. В обоих случаях вы выигрываете по спектру возможностей, сохраняя все остальные преимущества библиотеки форм.

Это расширение возможностей можно представить в виде кривой. На одном конце базовый вариант, который прост в написании, но ограничивает возможности контроля. На противоположном конце кривой будет специально созданный класс для форм со статическим у HTML-кодом, который обеспечивает больший уровень управления, но который и более сложен в создании. В примере с созданием форм эта кривая будет довольно гладкая, поскольку для всего спектра функций библиотеки форм существуют возможности постепенного замещения базовых опций на собственные пользовательские расширения.

До выхода в свет версии Django 1.2 для ORM такая кривая имела аналогичный вид, за одним исключением: существенный скачок в конце. Этот скачок появлялся в связи с тем, что при необходимости создания нестандартного SQL-запроса требовалось выйти за пределы ORM. Чтобы использовать определённый функционал ORM, пользователю пришлось бы создавать его заново самостоятельно, хоть это и не является само по себе катастрофой. В версии Django 1.2 добавлен метод Model.objects.raw (), который решает эту проблему и, таким образом, сглаживает эту кривую для ORM.

У форм в Django есть несколько предопределенных методов as_p(), as_table() и as_ul(), которые отображают форму как набор параграфов, таблицу или список. На практике этих методов не всегда достаточно, чтобы формы выглядели так, как нам хочется.

Допустим, верстальщик сверстал все формы div-ами. Документация предлагает в этом случае писать нужные теги в ручную в шаблоне. Если форма у нас только одна, можно поступить и так. Если форм несколько, то этот подход сразу же теряет все свое очарование. Решение очень простое — пронаследуем наш собственный класс форм от forms.Form или forms.ModelForm и обучим его рисовать формы так, как нужно нам.

Изначально Django предполагал работу только с одной базой данных (системное ограничение включающее такие вещи как группа настроек DATABASE_*). В течение всего этого времени явно ощущалась необходимость поддержки возможности работы с несколькими БД. В рамках работы над версией 1.2 в течение Google Summer of Code поддержка нескольких БД была включена в trunk. С этими новшествами связаны как целый ряд внутренних изменений, так и несколько удачных расширений для существующих интерфейсов работы с БД.

Есть несколько обыденных вещей, которые время от времени портят кровь нашему брату: падежи, числительные и часовые пояса, с проклятым переходом на летнее/зимнее время. Невольно позавидуешь китайцам у которых на всю страну всего один часовой пояс, а падежей нет и в помине. Будет совсем неплохо раз и навсегда разобраться с часовыми поясами и преобразованиями между ними хотя бы для Django-приложений.

Свершилось, товарищи! Несмотря на почти двухмесячную задержку и постоянные переносы даты релиза, сегодня, 17 мая 2010 года, финальная версия 1.2 великолепного фреймворка увидела свет.

Кратко напомню, какие же произошли самые заметные изменения и дам ссылку на более подробную информацию.

Армия потенциальных пользователей Вашего сайта, зарегистрированных в социальной сети Вконтакте.ру наверняка оценят по достоинству Ваши старания по внедрению регистрации с помощью их любимой социалки. О создании такой возможности я задумался сегодня по утру и не откладывая решил воплотить желание в реальность.

Облегчало реализацию два факта: первый заключается в том, что Open API мне очень напоминал Facebook Connect, с которым я уже работал. Второй факт был ещё весомей — у меня уже есть библиотека в которой каждый вариант авторизации (OpenID, OAuth, FacebookConnect) являются отдельными бэкендами и написать дополнительный, тем более так похожий на FC не выглядело сложным заданием. В итоге, можно сказать что по факту это действительно оказалось плёвым делом.

Итак, что же нужно для авторизации по Вконтакте.ру?

В этой захватывающей статье я расскажу про инструменты, с помощью которых можно писать функциональные тесты для django-проекта. Есть куча разных других способов это делать, но я опишу один — тот, который, на мой взгляд, самый простой. Между делом создадим красивый отчет по code coverage (субъективно — приятнее тех, что делает coverage.py). И еще, в качестве приправы, будет немного болтовни про тестирование.

CSRF, или Cross-Site Request Forgery (межсайтовая подделка запроса) — это, возможно, одна из самых забываемых уязвимостей. Разработчики, как правило, знают о SQL инъекциях и XSS атаках, но очень часто забывают о CSRF-атаках.

Django предоставляет отличные средства для быстрого построения back-end без лишних телодвижений. Однако создание на его основе галлереи связано с множеством ручной работы по загрузке каждого файла в отдельности.

Решений у этой проблемы несколько:

1. загрузка архива и его распаковка на сервере,
2. использование специального поля,
3. имитация множественных post-запросов.

Я выбрал последний вариант, так как в этом случае нужно внести минимум изменений. Все операции выполняются на клиенте. Использовать для этого будем swfuploader.

Задумка проста, модифицируем стандартный интерфейс добавления, так что бы перехватывать событие сохранения объекта. Заполненные поля будем использовать в качестве шаблона для создания множества объектов для выбранных файлов.

Итак выполним следующие действия.

Недавно, при работе над проектом на Джанго, понадобилось автоматически отправлять в твиттер заголовок и укороченную ссылку для публикуемых статей от имени пользователя.

Как оказалось, делается это совсем несложно.

Ох этот скромный {% if %}. Краеугольный камень шаблоной логики Django.

Каждый, кто начинал работать с Django 1.1 (или ранее), почти наверняка спотыкался об этот камень — шаблонный тег {% if %} поддерживает булеву логику только на базовом уровне.

В сегодняшних веб-приложениях часто требуется выдать посетителю некоторое оповещение. Будь то «Ваш комментарий сохранён и ожидает модерации» или же «Благодарим за проявленный интерес, мы обязательно вышлем Вам приглашение, как только откроемся», эти небольшие сообщения появляются то тут, то там постоянно, так что весьма здорово иметь удобный интерфейс для отображения их пользователю.

Идущее в поставке с Django приложение аутентификации и авторизации (django.contrib.auth) всегда включало базовый функционал для отображения всплывающих сообщений пользователю, но он имел несколько досадных недостатков. В Django 1.2 же теперь есть совершенно новый фреймворк для таких сообщений, написанный в первую очередь Тобаясом Макналти (Tobias McNulty).

Агрегатные функции в Django ORM — крутые. Это обстоятельство послужило поводом добавить еще одну =)

Далее речь пойдет о mysql-специфичной функции GROUP_CONCAT и волшебных розовых пони, как на картинке django-trunk.

От переводчика

Данную статью я прочитал на Django Advent приуроченному к уже скорому выходу Django 1.2 и она показалось мне настолько интересной, что я решил ее перевести. Далее текст статьи.

Когда разрабатываешь сайт на Джанго, так легко просто открыть консоль и напечатать:

python manage.py runserver

С этой простой командой управления ваши медиа файлы админки сайта поддерживаются правильным образом, PYTHONPATH правильно настроен и включает корневую папку нашего проекта, а так же запущен автоматически перегружающийся веб-сервер на указанном нами порту (от переводчика: по умолчанию порт 8000). Так просто!

Не удивительно, что люди так разочаровываются, когда приходит время положить их сайт на боевой сервер: существует так много шагов в этом процессе и поэтому сложно все их выучить и сделать все правильно. Неудивительно, что вся эта сложность приводит к тому, что написано много статей о развертывании веб-сайта на Джанго. Но почти все из этих статей фокусируются на развертывании сайта используя Apache и mod_wsgi или mod_python.

Однако иногда Apache не идеальное решение. Может быть ваш VPS имеет только 256 МБ памяти, а может быть вы хотите избежать сложности настройки Apache при установке. Или может быть вам просто не нравиться Apache. По любой из этих причин мы можем обратить свое внимание на FastCGI.

Редактировать модели, представляющие собой деревья в админке django очень неудобно и ненаглядно. Сразу возникло желание выводить вместо списка объектов дерево, для этого можно использовать замечательную библиотеку jstree.
Чтобы эффективно работать с деревьями в django существует mptt, которая добавляет в модель поля для эффективной выборки и методы для этого, а также шаблонные теги для вывода деревьев и т.п.
Если вы не используете mptt, у вас есть просто ссылка на parent — jstree можно подключить к с помощью одного javascript, про это — отдельная статья.
Далее про модели, использующие mptt.

Changeset 12297

Хорошо это или плохо, решайте сами :)

Формы являются одной из самых вкусных вещей в Django (после моделей, админки, url-маршрутизации и т.д.). Перед вами небольшое, но ёмкое руководство по их использованию, представляющее собой разбор 8 часто встречающихся ситуаций при программировании форм.

Доброго времени суток, уважаемый All!

Хочу представить на суд хабрасообщества проект, над которым я работал последнее время. Очень хочу получить конструктивную критику и предложения по его улучшению.

Описание проекта

DTemplate — проект с открытым исходным кодом, который дает возможность пользователям django иметь многочисленные инструменты упрощающие работу при создании нового django проекта без необходимости настраивать их каждый раз.

DTemplate создавался для собственных целей из уже существующих приложений с открытым кодом. Публикуя данный проект я хотел бы выразить огромную благодарность людям, которые предоставили возможность доступа к своим интеллектуальным трудам.