piumosso18 мар 2011 в 11:26

Наш опыт работы с Django, или 10 полезных модулей, облегчающих жизнь

4 мин

39K

Django *

+92

Комментарии 59

alrond 18 мар 2011 в 11:36

я бы добавил к незаменимым вещам — werkzeug, без него как без рук при разработке.

zzeus 18 мар 2011 в 12:44

С нормальной IDE и дебаггером, можно и без него )

dmitriko 18 мар 2011 в 13:05

Я всегда думал что werkzeug + jinja2 + sqlalchemy + wtforms вместо django, а не вместе.
Что то упускаю?

oleg_podsadny 18 мар 2011 в 13:22

В векрцойке есть экстеншн и менеджмент команда ./manage.py runserver_plus

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

ingspree 18 мар 2011 в 13:34

> В векрцойке есть экстеншн и менеджмент команда ./manage.py runserver_plus

Это не в веркцойге. Это аппликейшен для джанги, который юзает веркцойг.

oleg_podsadny 18 мар 2011 в 13:41

а — да, вот он code.google.com/p/django-command-extensions/wiki/RunServerPlus

dmitriko 18 мар 2011 в 14:08

Да, иногда сильно не хвататет Соловьева или Подсадного за соседним столом :)

alrond 18 мар 2011 в 13:27

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

#!/usr/bin/env python

import os, sys

from os.path import abspath, dirname

from werkzeug import run_simple, DebuggedApplication

from django.views import debug

from django.core.handlers.wsgi import WSGIHandler



def null_technical_500_response(request, exc_type, exc_value, tb):

 raise exc_type, exc_value, tb

debug.technical_500_response = null_technical_500_response



os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

path = os.path.abspath(dirname(dirname(abspath(__file__))))

sys.path.append(path)



if __name__ == '__main__':

 run_simple('www.site.com', 8000, DebuggedApplication(WSGIHandler(), True), True)

dmitriko 18 мар 2011 в 14:05

круто!

Zada 18 мар 2011 в 20:53

Да werkzeug + jinja2 + sqlalchemy + wtforms = Flask

dmitriko 19 мар 2011 в 14:59

спасибо, пригодится :)

vixh 19 мар 2011 в 13:55

так же к незаменимым стоит добавить django-templatetag-sugar, при установуке sentry он поставиться как зависимый

burdyugova 18 мар 2011 в 11:38

А почему твиттера нет в числе сервисов через которые можно залогиниться?

piumosso 18 мар 2011 в 11:40

Пока нет (ориентировались на самые популярные для нашей аудитории), но скоро будет.

l_nagash 18 мар 2011 в 12:07

Свой вариант реализации авторизации на GitHub-e выложите?

P.S. Firefox и Chrome блокирует Vkontakte при авторизации

Prophet 18 мар 2011 в 12:10

Пока для опенсорса слишком сыровато. Но планы выложить есть, да.

spanasik 18 мар 2011 в 15:54

Выкладывайте, допилим :-)

klen 18 мар 2011 в 16:09

Я тоже в свое время взял за основу publicauth и запилил свою реализацию: github.com/klen/django-netauth

Вот только до mail.ru руки не доходили, но пользовать можно вполне. Мб ребята кинут патч на openid.

kmike 18 мар 2011 в 12:12

Совсем скоро выйдет django 1.3, там будет замечательный django.contrib.staticfiles. И вы, наверное, столкнетесь с проблемой, если захотите на него перейти, т.к. django-compress по-нормальному работать не будет больше, да и вроде никто его не поддерживает и не развивает уже долгое время. Поэтому лучше бы пораньше перейти на что-то другое (я бы выбирал между github.com/miracle2k/webassets и github.com/jezdez/django_compressor).

Prophet 18 мар 2011 в 12:23

Мы уже используем 1.3RC в продакшене, правда пока без staticfiles. Обязательно пристально посмотрим на альтернативы compress, модуль django-compress действительно не развивается.

freebeer 18 мар 2011 в 12:37

Большое спасибо за то, что показали webassets. Используем django_compressor, но в нем не хватает management command. WebAssets в свою очередь похоже включает все лучшее из compressor'а и compress'а.

prefer 18 мар 2011 в 12:22

Взял пару модулей на заметку. Спасибо :)

immaculate 18 мар 2011 в 12:22

Я сессии целиком храню в cookie. Если сессия небольшая (чаще всего так и есть), то она без проблем помещается в cookie, при этом не создает никакой нагрузки на базу, ни единого запроса. Точно так же поступил с сообщениями (теми, что messages.add_message).

immaculate 18 мар 2011 в 15:54

За что минусы? Можно в двух словах написать, в чем моя глобальная ошибка?

Сессии в куках храню не только я, куки, естественно, зашифрованные и подписанные. Что в этом криминального?

VolCh 18 мар 2011 в 22:57

Как вариант — расшифровка/зашифровка, проверка аутентичности и валидация могут создавать большую нагрузку, чем обращение к БД и, тем более, к кэшу в ОЗУ. Плюс традиционное недоверие к данным, поступающим от пользователя.

immaculate 18 мар 2011 в 23:48

Ну, я не верю, что roundtrip к базе данных может быть быстрее, чем расшифровка/зашифровка. Бенчмарков не проводил, но просто не верится, что это может быть. Тем более, что у меня база на отдельном сервере. В отчетах о медленных запросах (pgfouine) постоянно фигурировала таблица django_session.

После внедрения этого нехитрого решения нагрузка на сервер с базой данных заметно снизилась.

navar 18 мар 2011 в 12:27

Очень полезная статья. Спасибо! Особенно понравилась идея из раздела «Кеширование».

bekbulatov 18 мар 2011 в 12:35

Почему схема БД не позволяла использовать select_related? Просто модели были не связаны или что?

piumosso 18 мар 2011 в 12:36

Они связаны необязательными связями.

Zada 18 мар 2011 в 21:01

Это не предлог.

Note that, by default, select_related() does not follow foreign keys that have null=True.

Но это ж только by default.

You can refer to any ForeignKey or OneToOneField relation in the list of fields passed to select_related. Ths includes foreign keys that have null=True (unlike the default select_related() call).

zzeus 18 мар 2011 в 12:45

А что за модуль в итоге отвечающий за страницы получился? И где форк pyblicauth лежит? ;)

НЛО прилетело и опубликовало эту надпись здесь

piumosso 18 мар 2011 в 12:49

Да, это кусок fein-cms; про него не писали.

equeny 18 мар 2011 в 12:48

А не хотите выложить ваши доработки publicauth куда-нибудь в open-source?

piumosso 18 мар 2011 в 12:49

Возможно, но пока они сыроваты

laQie 18 мар 2011 в 12:52

А почему нету django-annoying и django-command-extensions? Очень удобные штуки.

piumosso 18 мар 2011 в 12:54

django-annoying используем) полезняшки

StopDesign 23 мар 2011 в 15:01

Что именно из него?

Лично я не понимаю, чем вот это:

@render_to('template.html')
def foo(request):          
    bar = Bar.object.all()  
    return {'bar': bar}

лучше этого:

def foo(request):
    bar = Bar.object.all()  
    return render_to_response('template.html', {'bar': bar}, context_instance=RequestContext(request))

К тому же, HttpResponse, в который все и приходит в итоге, понимает ряд дополнительных параметров, которые иногда нужны: mimetype, status, content_type.

И остальное в том же духе. Набор разнородной фигни.

piumosso 23 мар 2011 в 17:44

Ну вот когда нужны параметры HttrResponse, тогда и пишем по-старинке.
А render_to улучшает читаемость, имхо.
Плюс view-ункция возвращает словарь, и я могу, например, написать декоратор, который будет с нима что-нить делать.

StopDesign 23 мар 2011 в 18:36

Мне в render_to нравится только то, что название шаблона стоит рядом с названием метода. Это удобно, если метод большой. Пожалуй, можно дописать поддержку параметров и положить в свой модуль.

Но вообще, это уже на грани добра и зла, мне кажется.

Недавно видел проект, в котором реализован тег google-analytics. То есть, программист подключает новую зависимость только для того, чтобы не копировать в проект 5 строк кода руками!

Это стремление к бесполезной красоте кода (которой иногда находят даже какие-то псевдо-логичные объяснения) — симптом обсессивно-компульсивного расстройства :-)

piumosso 23 мар 2011 в 18:58

А что если у меня 10 проектов, в которых нужен google analytics?

StopDesign 23 мар 2011 в 19:12

Ну, круто. Значит, продуктивно работаете.

Новая зависимость на такую ерунду потенциально принесет больше проблем, чем пользы. Скопипастить код гугла (а вам же нужно где-то брать его ID) будет быстрее, чем прописывать зависимость и подключать приложение. Да, в вашем шаблоне будет, о боже, неприкрытый js-код.

piumosso 23 мар 2011 в 19:33

))
Я и сам с этими мыслями борюсь. Скопипастить — это ж так «очевидно»…

laQie 18 мар 2011 в 17:42

прошу прощения, django-extensions лучше брать с гитхаба

teonoman 18 мар 2011 в 12:53

Вот это от души! Спасибо, ребята. Круто.

НЛО прилетело и опубликовало эту надпись здесь

qwertysx 18 мар 2011 в 14:07

Там в джанго все так интересно, обязательно нужно будет написать на нем что-нибудь)

Chikiro 18 мар 2011 в 14:25

Мне нравится django-debug-toolbar, использую в основном для отслеживания запросов к базе.

piumosso 18 мар 2011 в 14:27

Да, кстати))

offline15 18 мар 2011 в 15:36

Я видел одну переделку publicauth на github, это не ваша?

Prophet 18 мар 2011 в 15:41

Не наша. Там было что-то подобное?

offline15 18 мар 2011 в 16:12

Вообще я не уверен что это именно переделка или это я щас не ту либу нашёл которую в прошлый раз видел, но подход похож github.com/omab/django-social-auth
Правда слишком много кода почему-то, в моей publicauth по-моему проще всё как-то :)

offline15 18 мар 2011 в 16:13

Во, там выше в комментах дали правильный линк github.com/klen/django-netauth

l_nagash 18 мар 2011 в 16:18

На сайте у Вас миниатюры изображений круглой формы. Я так понимаю для этого использовался sorl-thumbnail со специальными настройками? Если да, можно пример? :)