Django *

Началось всё с того что надо было часто создавать однотипные формы и сохранять введённые данные в базу. По суте форма всегда одна и та же — «Заявка на регистрацию» — но в зависимости от мероприятия поля в ней разные.

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

Сия заметка, плод трудов хабра-человека sevenov, ему и почёт, дабы в будущем ему хватило кармы оставить свой след на хабре самому ;)

~~~~

Сегодня возник вопрос о том, как сделать вот так:



После получасового гугления наткнулся на несколько тикетов на code.djangoproject.com (ссылок сейчас не подкину, в истории искать лень). В общем, суть их в том, что нужно переписать чуть ли не половину 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?