Django *

За то время, пока я занимаюсь внедрением проектов, написанных на Django, накопились простые приемы упрощающие деплой. Разберем settings.py, который был использован в одном из последних проектов. Полностью файл доступен на http://gist.github.com/214361
Начнем.

Локальные настройки:

Локальные настройки позволяют иметь разные конфигурации одного проекта на разных машинах. В конце каждого моего файла settings.py есть подключение local_settings.py. Это позволяет переопределить любые значения переменных из settings.py. Например, на продакшн сервере я использую mysql, а на локальной машине — sqllite.

try:
    from local_settings import *
except ImportError:
    pass


8 сентября 2010 года разработчики Django выпустили релиз 1.2.2 чтобы закрыть уязвимости, позволяющие злоумышленникам устраивать XSS-атаки. По злой иронии, уязвимость к XSS оказалась в коде системы, выполняющем защиту от другого типа атак – CSRF. Система эта принципиально изменилась в версии 1.2 (в предыдущих версиях защита от CSRF не являлась частью ядра фреймворка и была всего лишь подключаемым слоем).

31 августа были подведены итоги международного конкурса по программированию Django Dash.

Целью конкурса было создать веб-приложение за 48 часов в команде из 3 человек. В соревновании принимали участие 51 команда из всех частей света.

1 место Great Big Crane от West meets West

Great Big Crane это application server для Django и Python проектов. То есть он ставится на сервер и в пару кликов развертывает вам новое веб-приложение. Развертыванием всех проектов на сервере теперь можно удобно управлять из единого интерфейса.

Все больше наших клиентов используют в своих проектах замечательный web-фреймворк Django и неудивительно. Ведь данный фреймворк позволяет очень быстро создавать динамические сайты и обладает при этом огромной гибкостью. Он имеет в своем арсенале множество готовых решений почти на все случаи жизни, и по-сути, является низкоуровневым конструктором сайтов. А главное его достоинство – это гибкость, благодаря которой, можно в короткие сроки создавать абсолютно любые по сложности веб-приложения.

Данный фреймворк имеет удобный встроенный веб-сервер, на котором можно без проблем отлаживать ваше приложение, но для реального боевого использования он естественно не годится.

Тут будет немного показано, как создать Django-проект, путем импортирования из существующего.
Создать Git-репозиторий, и основные функции использования репозитория.

Несмотря на то, что я уже видел, на хабре, парочку статей на тему использования и настройки Aptana IDE, решил продолжить тему, т.к. она ещё не до конца освещена.

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

Например, здесь описано как скрестить Eclipse и Redmine.

А здесь — введение в работу с Aptana, её установки и настройки. В некоторых моментах могу повторить, что есть там, и на хабре.

Перед тем, как делать скриншоты были предустановленны PyDev и Git. Наверное всем легко будет разобраться, как это сделать. Тем более, что стартовая страница приветствия Aptana, после установки, сразу предлагает установить новые модули, в числе которых их и можно найти.

Предлагаю всем высказаться, на тему того — как сами её используете, и показать это в картинках.

В субботу, 14 августа, в 8:00 по Москве начнётся соревнование DjangoDash, и скромная русская команда e-Legion решила поучаствовать в этом мероприятии. Кстати, в конкурсе участвует и, например, широко известный в узких кругах джангистов Malcolm Tredinnick (да, я тоже не понял почему команда с двумя участниками называется «три слепые мыши»).

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

И тут на помощь приходит 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).