Комментарии 17
Ну зачем, зачем в статье листинг CSS на четыре экрана?
+7
автор зачем $cat src
это статья или что?
это статья или что?
+4
Ну вот НИКОГДА не делайте так:
import * — в случае с настройками это зло. вот будет выкатывать проект человек не знакомый с ним, замучается
искать откуда что берется в settings.py
try:
from local_settings import *
except ImportError:
pass
import * — в случае с настройками это зло. вот будет выкатывать проект человек не знакомый с ним, замучается
искать откуда что берется в settings.py
-3
а как вы предлагаете разделять глобальные настройки, которые лежат в SVN/Mercurial/Git и локальные, которые должны отличаться между боевыми, тестовыми и локальными серверами?
Я знаю только 2 способа: первый как описан тут, второй — чтобы в настройках wsgi указать local_settings, а в них сделать
Я знаю только 2 способа: первый как описан тут, второй — чтобы в настройках wsgi указать local_settings, а в них сделать
from global_settings import *
+1
Очень просто, явное лучше неявного:
try:
import local_settings as ls
except ImportError:
...
...
HOSTNAME = ls.HOSTNAME
DATABASE_USER = ls.DATABASE_USER
...
+2
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"]
...
0
Я обычно делаю так:
И все настройки сбрасываю в settings/* по порядку. Туда же можно подложить какой-нибудь локальный конфиг.
В последнем «99-debug.conf.py» пишу «if DEBUG:» и переопределяю там настройки. Вдобавок несложно чуть-чуть переписать скрипт так, чтобы в случае с debug, он дергал настройки из settings_debug, например, как-то так:
А если в большинстве случаев release_config == debug_config, то, наверное, можно заюзать симлинки. Имхо, плюс такого подхода, как минимум, в том, что настройки каждого app вынесены в отдельный файл.
# 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 вынесены в отдельный файл.
+1
Всякие local_settings стоят в gitignore обычно. И тот, кто выкатывает, его пишет сам по мануалу от разработчика.
+3
Этот способ позволяет локально переопределять любые settings, включая дефолтные (не описанные в проектном settings.py). Плюс, он достаточно распространен, поэтому вряд ли у человека, видевшего хотя бы пару django-проектов, возникнут проблемы с поиском настроек. Да и другие способы заметно усложняют код и/или деплой, либо вообще не работают без явно созданных настроек, либо еще что-нибудь.
+2
Автору спасибо. Более опытные будут всегда говорить зачем тут что то лишнее описывать.
+3
Плохая статья, мне не нравится =(
Насчет проверки 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, как выше посоветовали. Меньше проблем со старыми браузерами.
Насчет проверки 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, как выше посоветовали. Меньше проблем со старыми браузерами.
+3
try:
from local_settings import *
except ImportError:
pass
Приятно видеть, что кто-то делает ровно также как ты, вплоть до названия модулей))
from local_settings import *
except ImportError:
pass
Приятно видеть, что кто-то делает ровно также как ты, вплоть до названия модулей))
+1
хуже оформленной статьи я просто не видел.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
WebSocket-чат на Tornado для вашего Django-проекта