Комментарии 59
я бы добавил к незаменимым вещам — werkzeug, без него как без рук при разработке.
С нормальной IDE и дебаггером, можно и без него )
Я всегда думал что werkzeug + jinja2 + sqlalchemy + wtforms вместо django, а не вместе.
Что то упускаю?
Что то упускаю?
В векрцойке есть экстеншн и менеджмент команда ./manage.py runserver_plus
С ее помощью запускается дев сервер на базе веркцойка и в темплейт дебаге можно выполнить питон команду или посмотреть переменную поглубже.
Мелочь, а приятно
С ее помощью запускается дев сервер на базе веркцойка и в темплейт дебаге можно выполнить питон команду или посмотреть переменную поглубже.
Мелочь, а приятно
Маленький скрипт внизу, и вы можете запускать локально ваш проект на 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)
Да werkzeug + jinja2 + sqlalchemy + wtforms = Flask
так же к незаменимым стоит добавить django-templatetag-sugar, при установуке sentry он поставиться как зависимый
А почему твиттера нет в числе сервисов через которые можно залогиниться?
Свой вариант реализации авторизации на GitHub-e выложите?
P.S. Firefox и Chrome блокирует Vkontakte при авторизации
P.S. Firefox и Chrome блокирует Vkontakte при авторизации
Пока для опенсорса слишком сыровато. Но планы выложить есть, да.
Я тоже в свое время взял за основу publicauth и запилил свою реализацию: github.com/klen/django-netauth
Вот только до mail.ru руки не доходили, но пользовать можно вполне. Мб ребята кинут патч на openid.
Вот только до mail.ru руки не доходили, но пользовать можно вполне. Мб ребята кинут патч на openid.
Совсем скоро выйдет django 1.3, там будет замечательный django.contrib.staticfiles. И вы, наверное, столкнетесь с проблемой, если захотите на него перейти, т.к. django-compress по-нормальному работать не будет больше, да и вроде никто его не поддерживает и не развивает уже долгое время. Поэтому лучше бы пораньше перейти на что-то другое (я бы выбирал между github.com/miracle2k/webassets и github.com/jezdez/django_compressor).
Мы уже используем 1.3RC в продакшене, правда пока без staticfiles. Обязательно пристально посмотрим на альтернативы compress, модуль django-compress действительно не развивается.
Большое спасибо за то, что показали webassets. Используем django_compressor, но в нем не хватает management command. WebAssets в свою очередь похоже включает все лучшее из compressor'а и compress'а.
Взял пару модулей на заметку. Спасибо :)
Я сессии целиком храню в cookie. Если сессия небольшая (чаще всего так и есть), то она без проблем помещается в cookie, при этом не создает никакой нагрузки на базу, ни единого запроса. Точно так же поступил с сообщениями (теми, что messages.add_message).
За что минусы? Можно в двух словах написать, в чем моя глобальная ошибка?
Сессии в куках храню не только я, куки, естественно, зашифрованные и подписанные. Что в этом криминального?
Сессии в куках храню не только я, куки, естественно, зашифрованные и подписанные. Что в этом криминального?
Как вариант — расшифровка/зашифровка, проверка аутентичности и валидация могут создавать большую нагрузку, чем обращение к БД и, тем более, к кэшу в ОЗУ. Плюс традиционное недоверие к данным, поступающим от пользователя.
Ну, я не верю, что roundtrip к базе данных может быть быстрее, чем расшифровка/зашифровка. Бенчмарков не проводил, но просто не верится, что это может быть. Тем более, что у меня база на отдельном сервере. В отчетах о медленных запросах (pgfouine) постоянно фигурировала таблица django_session.
После внедрения этого нехитрого решения нагрузка на сервер с базой данных заметно снизилась.
После внедрения этого нехитрого решения нагрузка на сервер с базой данных заметно снизилась.
Очень полезная статья. Спасибо! Особенно понравилась идея из раздела «Кеширование».
Почему схема БД не позволяла использовать select_related? Просто модели были не связаны или что?
Они связаны необязательными связями.
Это не предлог.
Но это ж только by default.
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).
А что за модуль в итоге отвечающий за страницы получился? И где форк pyblicauth лежит? ;)
НЛО прилетело и опубликовало эту надпись здесь
А не хотите выложить ваши доработки publicauth куда-нибудь в open-source?
А почему нету django-annoying и django-command-extensions? Очень удобные штуки.
django-annoying используем) полезняшки
Что именно из него?
Лично я не понимаю, чем вот это:
лучше этого:
К тому же, HttpResponse, в который все и приходит в итоге, понимает ряд дополнительных параметров, которые иногда нужны: mimetype, status, content_type.
И остальное в том же духе. Набор разнородной фигни.
Лично я не понимаю, чем вот это:
@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.
И остальное в том же духе. Набор разнородной фигни.
Ну вот когда нужны параметры HttrResponse, тогда и пишем по-старинке.
А render_to улучшает читаемость, имхо.
Плюс view-ункция возвращает словарь, и я могу, например, написать декоратор, который будет с нима что-нить делать.
А render_to улучшает читаемость, имхо.
Плюс view-ункция возвращает словарь, и я могу, например, написать декоратор, который будет с нима что-нить делать.
Мне в render_to нравится только то, что название шаблона стоит рядом с названием метода. Это удобно, если метод большой. Пожалуй, можно дописать поддержку параметров и положить в свой модуль.
Но вообще, это уже на грани добра и зла, мне кажется.
Недавно видел проект, в котором реализован тег google-analytics. То есть, программист подключает новую зависимость только для того, чтобы не копировать в проект 5 строк кода руками!
Это стремление к бесполезной красоте кода (которой иногда находят даже какие-то псевдо-логичные объяснения) — симптом обсессивно-компульсивного расстройства :-)
Но вообще, это уже на грани добра и зла, мне кажется.
Недавно видел проект, в котором реализован тег google-analytics. То есть, программист подключает новую зависимость только для того, чтобы не копировать в проект 5 строк кода руками!
Это стремление к бесполезной красоте кода (которой иногда находят даже какие-то псевдо-логичные объяснения) — симптом обсессивно-компульсивного расстройства :-)
А что если у меня 10 проектов, в которых нужен google analytics?
Ну, круто. Значит, продуктивно работаете.
Новая зависимость на такую ерунду потенциально принесет больше проблем, чем пользы. Скопипастить код гугла (а вам же нужно где-то брать его ID) будет быстрее, чем прописывать зависимость и подключать приложение. Да, в вашем шаблоне будет, о боже, неприкрытый js-код.
Новая зависимость на такую ерунду потенциально принесет больше проблем, чем пользы. Скопипастить код гугла (а вам же нужно где-то брать его ID) будет быстрее, чем прописывать зависимость и подключать приложение. Да, в вашем шаблоне будет, о боже, неприкрытый js-код.
прошу прощения, django-extensions лучше брать с гитхаба
Вот это от души! Спасибо, ребята. Круто.
НЛО прилетело и опубликовало эту надпись здесь
Там в джанго все так интересно, обязательно нужно будет написать на нем что-нибудь)
Мне нравится django-debug-toolbar, использую в основном для отслеживания запросов к базе.
Я видел одну переделку publicauth на github, это не ваша?
Не наша. Там было что-то подобное?
Вообще я не уверен что это именно переделка или это я щас не ту либу нашёл которую в прошлый раз видел, но подход похож github.com/omab/django-social-auth
Правда слишком много кода почему-то, в моей publicauth по-моему проще всё как-то :)
Правда слишком много кода почему-то, в моей publicauth по-моему проще всё как-то :)
Во, там выше в комментах дали правильный линк github.com/klen/django-netauth
На сайте у Вас миниатюры изображений круглой формы. Я так понимаю для этого использовался sorl-thumbnail со специальными настройками? Если да, можно пример? :)
Выложите, если не жметесь, библиотеку с авторизацией, которую «основательно допилили». Так Вы сможете помочь любимому фреймворку.
Большое спасибо, отличный топик
Обещали выложить авторизацию, а воз и ныне там. Пожалуйста, выложите! Ведь не хочется изобретать велосипед!
Вот отличное приложение: github.com/krvss/django-social-auth
В том числе поддержка российских соц. сетей: вконтакте, одноклассники, майл.ру
В том числе поддержка российских соц. сетей: вконтакте, одноклассники, майл.ру
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Наш опыт работы с Django, или 10 полезных модулей, облегчающих жизнь