WebSocket-чат на Tornado для вашего Django-проекта

[x1am]

Ну зачем, зачем в статье листинг CSS на четыре экрана?

[MechanisM]

Это Tutorial.

[DevEx]

автор зачем $cat src
это статья или что?

[Jekel]

Ну вот НИКОГДА не делайте так:

try:
    from local_settings import *
except ImportError:
    pass

import * — в случае с настройками это зло. вот будет выкатывать проект человек не знакомый с ним, замучается
искать откуда что берется в settings.py

[Yngvie]

а как вы предлагаете разделять глобальные настройки, которые лежат в SVN/Mercurial/Git и локальные, которые должны отличаться между боевыми, тестовыми и локальными серверами?

Я знаю только 2 способа: первый как описан тут, второй — чтобы в настройках wsgi указать local_settings, а в них сделать

from global_settings import *

[Jekel]

Очень просто, явное лучше неявного:

try:
    import local_settings as ls
except ImportError:
    ...
...
    HOSTNAME = ls.HOSTNAME
    DATABASE_USER = ls.DATABASE_USER
...

[MechanisM]

import os
...

SECRET_KEY = os.environ["SECRET_KEY"]

EMAIL_HOST = os.environ["EMAIL_HOST"]
EMAIL_PORT = int(os.environ["EMAIL_PORT"])
EMAIL_HOST_USER = os.environ["EMAIL_HOST_USER"]
EMAIL_HOST_PASSWORD = os.environ["EMAIL_HOST_PASSWORD"]
EMAIL_USE_TLS = True

AWS_ACCESS_KEY_ID = os.environ["AWS_ACCESS_KEY_ID"]
AWS_SECRET_ACCESS_KEY = os.environ["AWS_SECRET_ACCESS_KEY"]

...

[MechanisM]

или вообще весь settings.py другой(такой-же но заполненный реальными данными) подставлять при запуске проекта:

import os

os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.production'

[lilo_panic]

Я обычно делаю так:

# settings.py
DEBUG=True
DEBUG=False
config_files_path = os.path.join(PROJECT_PATH, 'settings', '*.conf.py')
config_files = glob.glob(config_files_path)
config_files.sort()

for f in config_files:
    execfile(os.path.abspath(f))

И все настройки сбрасываю в settings/* по порядку. Туда же можно подложить какой-нибудь локальный конфиг.

00-db.conf.py
01-logging.conf.py
10-apps.conf.py
20-project.conf.py
21-middleware.conf.py
22-template_context_processors.conf.py
23-mailing.conf.py
25-debug_toolbar.conf.py
30-locale.conf.py
35-amazon_s3.conf.py
36-easy_thumbnails.conf.py
37-django_ajax_selects.conf.py
38-sentry.conf.py
.......
98-celery.conf.py
99-debug.conf.py

В последнем «99-debug.conf.py» пишу «if DEBUG:» и переопределяю там настройки. Вдобавок несложно чуть-чуть переписать скрипт так, чтобы в случае с debug, он дергал настройки из settings_debug, например, как-то так:

RELEASE='debug' if DEBUG else 'release'
config_files_path = os.path.join(PROJECT_PATH, 'settings', RELEASE,  '*.conf.py')

А если в большинстве случаев release_config == debug_config, то, наверное, можно заюзать симлинки. Имхо, плюс такого подхода, как минимум, в том, что настройки каждого app вынесены в отдельный файл.

[AgaFonOff]

Всякие local_settings стоят в gitignore обычно. И тот, кто выкатывает, его пишет сам по мануалу от разработчика.

[ilvar]

Этот способ позволяет локально переопределять любые settings, включая дефолтные (не описанные в проектном settings.py). Плюс, он достаточно распространен, поэтому вряд ли у человека, видевшего хотя бы пару django-проектов, возникнут проблемы с поиском настроек. Да и другие способы заметно усложняют код и/или деплой, либо вообще не работают без явно созданных настроек, либо еще что-нибудь.

[Huey]

Автору спасибо. Более опытные будут всегда говорить зачем тут что то лишнее описывать.

[chexov]

согласен :)
Спасибо автору за пост.
Хотя css я бы опустил.

[nvbn]

Рекомендую посмотреть в сторону sockjs, на голых вебсокетах большой пласт пользователей отвалится.

[seriyPS]

Плохая статья, мне не нравится =(

Насчет проверки UserID по базе данных внутри tornado — это плохая идея. Лучше пусть юзеру выдается кука/скрытое поле с текстом наподобие md5(user_id, SECRET_KEY), которое будет передаваться Tornado отдельным параметром. Tornado проверяет соответствует ли вычисленное значение переданному, исходя из этого решает пускать юзера или нет. Ну или продублируйте нужную информацию в Redis.
Выполнять блокирующие операции из Tornado не стоит, что-бы там ребята из FF не писали.

С Django вы явно недавно работаете, иначе бы ваши вьюхи раза в 4 короче были бы, см docs.djangoproject.com/en/1.4/topics/http/decorators/
Для валидации входящих данных используйте Django формы! Даже не смотря на то, что сами формы непосредственно на страницах не отображаются, это сильно упростит и структурирует код.

Попробуйте sockjs, как выше посоветовали. Меньше проблем со старыми браузерами.

[loststylus]

try:
from local_settings import *
except ImportError:
pass

Приятно видеть, что кто-то делает ровно также как ты, вплоть до названия модулей))

[Severovostok]

хуже оформленной статьи я просто не видел.