Django *

Приветствую вас вновь, дорогие читатели! Публикую очередную статью из цикла немного про Class Based Views (далее CBV) в Django. На этот раз я, как и планировал, хотел бы рассмотреть ListView (отвечает за отображение списка объектов) и DetailView (отвечает за отображение информации об отдельном объекте).

Часть 1, часть 2, часть 3, часть 4

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

Искал для себя шпаргалку. Не смог найти её здесь и нашёл у них) Делюсь с теми, кому она необходима, как и мне.
Оригинальная ссылка: PDF

UPD: Из-за периодического отсутствия доступа к файлу на оригинальном сайте Разместил у себя

Доброго времени суток, уважаемые читатели! Не так давно мной была опубликована первая часть статьи на данную тему. Я хочу еще раз поблагодарить всех пользователей, высказавших конструктивную критику, благодаря которой примеры в статье удалось привести к почти идеальному виду. В то же время я понял, что данный формат подачи материала является неэффективным: мы рассмотрели всего пару методов, реализованных в Class Based View (далее по тексту CBV). Во второй части я решил переработать подачу и далее постараюсь описать максимально возможное количество методов, представленных в API. Постараюсь, также, охватить те методы, которые были упущены в первой части. Очень надеюсь на конструктивную поддержку читателей и надеюсь, что и в дальнейшем у нас получится продуктивный диалог, в результате которого статья станет еще более информативной.

Вступление

Здравствуйте, уважаемые читатели! Для многих джанго-разработчиков не секрет, что с версии 1.3+ вместо используемых ранее generic views нам необходимо начинать использовать class based views. А с 1.4+ версии generic views вообще могут стать deprecated. Информация про class based views (далее CBV) в интернете довольно скупа (а в рунете и подавно). Нет, конечно есть превосходные статьи, в том числе тут на хабре. Одна из статей была опубликована буквально на днях. Но я отношусь к той категории людей, что привыкли все изучать на практике и данный топик написан для таких же людей.
В качестве практического задания мной был выбран классический вариант — создание блога. Для того, чтобы использовать возможности CBV по максимуму мы немного усложним задачу. Пусть это будет не просто блог, а блог, с возможностью публиковать приватные статьи, недоступные неавторизованным пользователям.
Дальнейшие рассуждения подразумевают, что читатель ознакомлен с фреймворком Django и имеет навыки в создании проектов.

В Django версии 1.3 были представлены class-based views — способ описания view в виде классов. Документация, однако, касается только generic views, не описывая общую технику написания «вьюх» в виде классов. Начав использовать generic views и затем пытаясь изменить их поведение, я постепенно дошел до того момента, когда мне пришлось смотреть исходный код, чтобы понять, как что-то сделать. Поэтому я решил написать этот текст. Цель его — объяснить, как использовать class-based view и чем это может быть полезно.

Некоторое время назад озадачился поиском способа развертывания проектов Django, к которому предъявлялись два требования:

1. Удобное управление запуском/остановкой/перезапуском нескольких проектов на одном хосте
2. Поддержка разных виртуальных сред для разных проектов

По второму пункту мой выбор склонился в пользу Nginx + uWSGI. По первому же, из рассмотренных мною вариантов больше всего понравились обвязки для uWSGI в Debian.

Когда мы подготавливали для Хабра свою последнюю статью о Django-батарейках, выяснилось, что про django-sphinx мы таки имеем что рассказать и наш рассказ тянет на отдельный пост. Собственно, вот он, как и обещали.

На сегодняшний день, существует несколько хороших решений для организации поиска в Django. Несколько — это два: Haystack и django-sphinx. Haystack работает с бэкендами-движками solr, whoosh и хapian и, увы, не работает со Sphinx`ом по каким-то абстрактным лицензионным причинам. django-sphinx же, как можно догадаться, работает со Sphinx`ом и только. Haystack это качественный, хорошо документированный и активно развиваемый продукт и мы, вне всяких сомнений, использовали бы именно его, если бы он хоть в какой-нибудь форме поддерживал Sphinx. Но этого, увы, пока не произошло. А Sphinx — наше всё, благодаря его скорости, гибкости и, что очень важно в наших географических широтах, способности учитывать особенности русской морфологии, чего не скажешь о его ближайших конкурентах. «Большие, но по 5… или маленькие, но по 3?»

Продолжаем делиться своим опытом использования полезных батареек для Django.
Первая часть
Ещё рекомендуем «Сумбурные заметки про python и django» и «Django проект PR Hero: что внутри и полученный опыт».

Для Django написано огромное количество пакетов. Из них мы выбрали 10, которые использовали сами в своих последних проектах и которыми остались довольны. Все они есть на PyPI. Они продокументированы и покрыты тестами, где-то больше, где-то меньше. Исключение составляет django-sphinx, о котором отдельно.

Буду краток:



Подробности, что еще не работает, и как это установить — под катом.

Введение

В процессе разработки, создавая новый функционал, всё чаще широкими мазками стал задевать старый код чем разрушал логику его работы. Это заставило всё-таки написать юнит и интеграционные тесты для старого кода и автоматизировать их запуск, т.к. гонять руками все тесты как-то грустно. Как раз вспомнилось недавнее руководство по CI Django в Jenkins и довольно старое по Webtest в Django. В итоге была совершена попытка поднять Дженкинса, но он как-то на моей убунте не взлетел и я грешным делом вспомнил про TeamCity. «Раз уж пишу в PyCharm и нашёл к нему подход, то, наверно, и TeamCity осилю, ведь конторка-то одна!» — подумалось мне… В общем-то я оказался прав, и, пока мне позволяет карма, решил подарить вам ультраполезный (и мегаподробный), в отличие от моего предыдущего, мануал :)

Итого: кому требуется руководство по поднятию интеграционного сервера TeamCity, и тестирование в нём Django проектов c тестами nose и webtest в виртуальном окружении python с автоматическим его (окружения) обновлением — добро пожаловать под кат.

Осторожно! Для работы TeamCity требуется (согласно документации) sun/oracle версия JVM…

Для начала всех хотелось бы поздравить с наступающими праздниками!

А теперь к сути моего повествования.

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

Для начала посмотрим, какой результат мы преследуем:

Разработчики великолепного фреймворка решили порадовать нас перед Новым Годом — и зарелизили 1.4 альфа версию!

Примерный график выхода версий:

• Неделя с 30 Января 2012: первый бета релиз.
• Неделя с 27 Февраля 2012: первый релиз кандидат.
• Неделя с 5 Марта 2012: финальный релиз.

Сразу обращу внимание, что Python 2.4 больше не поддерживается. Минимум — версия 2.5.

В этой статье я опишу как настроить Django так, что б на сервере в top'е можно было видеть нагрузку на сервер от каждого из Django-проектов.

django-hosts — полезное приложение от замечательного Jannis Leidel, который входит в состав Django core-developers и курирует большое количество Django-проектов.
Документацию можно найти на readthedocs.
Пример установки:

• Устанавливаем: pip install django-hosts
• Добавляем 'django_hosts' в INSTALLED_APPS
• Добавляем 'django_hosts.middleware.HostsMiddleware' в MIDDLEWARE_CLASSES
• В директории проекта создаем файлик назовем его например hosts.py
• Примерное содержание hosts.py:
  

  from django_hosts import patterns, host
  host_patterns = patterns('path.to',
      host(r'api', 'api.urls', name='api'),
      host(r'news', 'news.urls', name='news'),
      host(r'forum', 'forum.urls', name='forum'),
  )

  
  В соотвтетствии с файлом hosts.py у нас появятся 3 хоста: api.site.com, news.site.com, forum.site.com.
  
• В settings.py добавляем: ROOT_HOSTCONF = 'projectname.hosts'

Не забываем про настройку wildcard субдомена (Хотя не обязательно wildcard — достаточно прописать необходимые. Ну а как все это сделать думаю все знают).

Знаю что многие недолюбливают Pinax, поэтому особо много писать не буду — отделаюсь ссылочкой и парой заметок:

• Сделано несколько тем (я потратил немного свободного времени на создание темы на jquerymobile и чуток помог с темой на bootstrap)
• Много что изменилось, но до сих пор куча нюансов которые нужно рефакторить и рефакторить..(имхо)
• Оставили только 4 стартовых проекта (static,zero,basic,account мне так нехватает social_project из предыдущих версий..)
• До сих пор понять не могу почему они используют django-staticfiles вместо встроенного в django 1.3.x.

Почему стабильная в кавычках и в версии есть буква «a», намекающая на то что это альфа-версия и многое другое можно прочитать в блоге проекта.

Всем привет.

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

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

В качестве новой системы был выбран Jenkins, о его установке и настройке для django-проекта и пойдет речь в этой статье. Кто заинтересовался, добро пожаловать под кат.

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

Иногда приходится создавать с нуля сайт на Джанге. Это и тесты концепций, и простенькие странички (ведь если мы в проекте используем разные мощные инструменты, почему бы сайт-визитку не сделать тоже с их помощью, избавив себя от ручной работы?).

Итак, представляю публике проект под девизом «Поменьше писанины! Побыстрей, дебаг!» Набор для скоростной разработки на Джанго.

Это 2 шаблона:

• шаблон конфига buildout, который подтягивает и собирает все необходимые проекту пакеты
• шаблон проекта, а именно настройки, включающие все нужные инструменты, и набор статики (готовые файлы на Haml и Sass)

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

Некоторое время назад я писал о системе кеширования. Помнится, я обещал продолжение, но сейчас решил, что строка кода лучше сотни комментариев, теорию оставим на потом. Поэтому сегодня у нас своего рода анонс с парой советов по использованию в одном флаконе. Встречайте, cacheops — система кеширования и автоматической инвалидации кеша для Django ORM.