Django: Что самое идеальное место состоит в том, чтобы сохранить определенное для проекта промежуточное программное обеспечение?
Я знаю, что могу "сохранить его где-нибудь в моем пути Python" и всех, но что такое организованный шаблон, который я могу использовать для хранения классов промежуточного программного обеспечения для моего проекта?
Я добавляю свой корневой каталог проекта и каталог проекта к пути sys через mod_wsgi:
sys.path.append( '/srv/' )
sys.path.append( '/srv/workarounds/' )
Причем последняя строка является корнем проекта. Как пример, скажем, я хочу применить этот класс промежуточного программного обеспечения: http://djangosnippets.org/snippets/1179/
Я просто скопировал бы содержание отрывка в middleware.py файл и вывел бы его в моем корне проекта? Создайте каталог для промежуточного программного обеспечения, добавьте, что каталог к моему Python соединяет каналом?
2 ответа
Мой обычный макет сайта django выглядит так:
projects/
templates/
common/
local/
Где:
- projects содержит ваш основной проект и любые другие
- common содержит вещи, которые вы можете использовать совместно на разных сайтах, или, по крайней мере, не специфичные для проекта, например, если вам нужно загрузить django-profile и django-registration, а не иметь их непосредственно в python/site-packages
- templates содержит только это
- local содержит вещи, которые будут специфичны для текущей машины, так что вы можете иметь правильно разделенные данные, такие как расположение базы данных и пароль - я затем мягко связываю специфичные для машины версии (скажем, "machine1-localconfig. py") в local/localconfig.py и затем могу "import localconfig" в settings.py
Я обычно помещаю промежуточное ПО, специфичное для проекта, в проект, а промежуточное ПО, не специфичное для проекта, в common/middleware/
Убедитесь, что добавили каталог templates в нужное место в settings (или, скорее всего, localconfig.py и затем импортировали его в settings), и убедитесь, что добавили каталоги projects, common и local в ваш PYTHONPATH.
Если у вас всего пара тесно связанных классов промежуточного ПО, поместите их в модуль middleware.py под корнем приложения. (Именно так это делается в django.contrib приложениях - смотрите middleware приложения сессий здесь).
Если у вас много различных классов middleware, создайте пакет middleware pacakge с подмодулями соответствующих классов middleware. Хотя, если вы окажетесь в такой ситуации, подумайте, как можно рефакторить ваш проект на несколько мини-приложений, которые решают конкретную задачу (и выложить их в открытый исходный код :)).
Лично у меня есть общий пакет django, где я сбрасываю общее промежуточное ПО (например, связанный с вами класс LoginRequiredMiddleware) в пакет middleware. Если это имеет смысл в контексте вашего проекта, я бы очень рекомендовал это сделать. Это спасло меня от бесчисленных часов дублирования и исправления ошибок. django-common и django-annoying - хорошие примеры такого типа компоновки проекта