Django *

Неплохая а совсем даже хорошая новость для отечественных джангистов.
В рассылке джанги это я упомянул, стоит выложить для всех и на Хабр, поскольку у нас тема django-хостингов актуальна.
Недавно по различным вопросам переписывался с суппортом хостинга РУ-центра (hosting.nic.ru) и узнал, что на тарифах 201, 301 уже установлен django, текущая установленная версия 0.96
Пока никаких анонсов данного факта не производилось, так что вы получаете свеженькую инфу :)

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

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

Недавно Игорь Кононученко выложил версию типографа, написанного на Питоне. Игорю большое человеческое спасибо. А я скромно решил сделать из библиотеки типографический фильтр для django. Не то, чтобы это сложно — но новичкам, вроде меня, может пригодиться. Что, собственно, получилось.

Навеяно советом Артёма Горбунова.

Что позволяет делать:
— простым движением добавлять на страницу in-place или in-line редактирование переменных

Вот, впринципе, и всё.

http://code.google.com/p/django-inline/

Разработчики не спят, скорее бы релиз.

Только-только, всего четыре дня назад, долгожданная ветка newforms-admin была добавлена в trunk (что, похоже, сделало неактуальными соответствующую главу в The Django Book), не успели мы ещё все наши проекты адаптировать к NFA, как… ещё одна новость.

Из того факта, что NFA теперь в trunk-е, следует, что больше у нас объёмного кода, использовавшего oldforms, нет (за исключением разве что django.contrib.comments); а значит, newforms, как давно планировалось, можно переименовывать просто в forms,… и выпускать альфа-версию долгожданного релиза 1.0!

5-го августа ждём первую бету, 19-го августа — первый RC, а 2-го сентября — релиз.

Да нужны. Замечу, что речь идёт об автоматизированных тестах. Эта штука просто жизненно необходима для особо функционального (базового, низкоуровнего) кода, каковой содержит сам framework Django. Но почему бы не применить тесты для сайтов? И это не просто «по приколу», а некая защита от головняка.


Часто приходится обновлять Django и сопутствующие приложения на сервере, что иногда приводит к проблемам, которые крайне нежелательны на сайтах заказчиков. И главная проблема это 500 ошибка, которая и будет показателем отказа в тексте ниже.


Итак, Django предоставляет возможность писать тесты для приложений и это всё облегчает.


В большинстве сайтов, ничего не может обрушиться просто так, это скорее всего связано с обратно несовместимыми изменениями в Django, либо влиянием таких изменений на сторонние приложения (django-voting e.t.c.). Написав простейший тест, который проверит, а возвращает ли страница корректный код (т.е. 200) мы при первом же запуске всех тестов определим неработающие страницы, а соответственно и проблемный код.


Итак, в конце всего этого короткий код (за остальным, обратитесь к документации):

from django.test import TestCase

class LentaTest(TestCase):
    def test_index(self):
        response = self.client.get('/lenta/')
        self.failUnlessEqual(response.status_code, 200)

Код помещаем в appname/tests.py, а чтобы запустить тесты, делаем manage.py test appname

Опыт «забавностей» становится всё больше и больше. Вот очередной случай маразма. Коротко суть:

Существует сайт, на котором нужно выводить одни и те же объекты с разными условиями выборки (по категории, по тегу, «захабареные» и т.п.) и разными отображениями (список, подробно и т.п.).

Некоторые индивиды, создают в каждом view замысловатую структуру из if-ов, и каждый раз она повторяется. Запомните:

1. Рефакторинг
2. Рефакторинг
3. Рефакторинг
4. view — это просто функция!

И так, по последнему пункту.

В предыдущем посте было рассказано, как создать простейший проект на GAE + Django. Сейчас давайте попробуем подключить к проекту шаблоны Django и поддержку статических файлов — таблиц стилей, скриптов и картинок.

Наш Django проект будет называтся dvk, и содержать приложение main. В папке приложения создаем каталог для шаблонов templates:

dvk/
main.py
app.yaml
    dvk/
    manage.py
    settings.py
    urls.py
      main/
      __init__.py
      models.py
      views.py
        templates/

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

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

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

О Google App Engine не слышал уже наверное только ленивый. Использование фреймворка Django совместно с GAE дает в руки разработчика удобные инструменты для быстрого создания веб-приложений.

В этом туториале рассказывается, как создать простое Django приложение с использованием этой платформы. Предполагается, что у вас уже есть аккаунт в Google App Engine.

По мотивам топика вело-запчастей для руби.

Товарищи программисы лучшее враг хорошего!!!

отличный ресурс для поиска того что уже написано на: http://djangoplugables.com/

Я недавно «подсел» на Django и мне очень нравится этот фреймворк. Однако есть деталь, которая доставляет беспокойство. Это одновременное редактирование файла с моими views и файла urls.py при создании нового view. Я понимаю, что это связано с тем, что URL-ы и views вещи достаточно разные и для большей модульности лучше держать их раздельно, однако для небольших проектов было бы очень удобно иметь возможность править view и его настройки в одном месте.

Здесь я предлагаю такое решение, конечно же, завязанное на декораторах.

Долгожданная ветка queryset-refactor наконец-то слита с основной рабочей веткой trunk (изменение r7477). Официальная документация для trunk-а на сайте тоже обновлена.
Что это значит для всех нас?

Я делаю на Django Энциклопедию языков программирования, о которой уже писал на Хабре. За время работы сайта выяснилось, что нужен свой выделенный сервер для большей производительности и стабильности. Пока что взял дешевый сервер с 1.8 ГГц процессором и 512 Мб памяти.

В этой статье я расскажу об установке и настройке на этом сервере Django с mod_python для Apache, с кэшированием memcached и lighttpd для статических файлов.

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

спасибо за тэги, но сразу же назревает вопрос — как нам тэги заhrefать? да еще научить, что бы выбирал объекты с запрошенными тэгами

Добавить обработку тэгов в URLах несложно, например можно использовать урлы вида "/tag/ИМЯ_ТЕГА/"

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

Прочитал статью «Фрагментарное кэширование в MVC веб-фреймворках». Статья описывает проблему кеширования фрагмета отображения, а именно проблему полного разделения контроллера и отображения — контроллер отрабатывает полностью до вызова отображения. Если в отображении мы кешируем фрагмент, это ничего не меняет — контроллер-то уже отработал! В статье описан способ этого избежать: сделать запрос данных «ленивым».

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

Как это сделано в Django?

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

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

Продолжение возни с тэгами.

Django-tagging 0.2.1 я не похачил, а наоборот — взял всё самое лучшее из него и перенёс в версию 0.1. Таким образом получилось совместимое с Django 0.96 приложение с готовыми инструментами для создания облака тэгов.

Скачать можно с моего сайта (34Kb). Просто распакуйте архив в папку проекта и добавьте это приложение в INSTALLED_APPS.

#settings.py
…
INSTALLED_APPS = (
    …
    'myproject.tagging',
)

Очень просто добавить тэги к любой модели вашего проекта. Для этого нужно импортировать из django-tagging поле TagField