Проектирование проекта/компоновка FS для крупных проектов джанго

Каков наилучший способ компоновки большого проекта django? Учебные пособия содержат простые инструкции по настройке приложений, моделей и представлений, но меньше информации о том, как приложения и проекты должны быть разбиты, сколько разделов допустимо/необходимо между приложениями в типичном проекте (очевидно, что в значительной степени зависит от проект) и как/где общие шаблоны должны быть сохранены.

Есть ли у кого-нибудь примеры, предложения и объяснения относительно того, почему конкретный макет проекта лучше другого? Меня особенно интересует включение большого количества модульных тестов (2-5x размер фактической базы кода) и экстернализации строк/шаблонов.

Ответ 1

Основные рекомендации похожи на любой другой проект с большим кодом. Приложения должны учитывать единую четко определенную ответственность. Имя "приложение" является неправильным; Приложения Django следует рассматривать как дополнительные компоненты, которые могут быть подключены друг к другу для создания реального приложения. Тесты для каждого приложения должны содержаться в этом приложении. Приложения должны быть отделены друг от друга как можно больше, но, очевидно, будут зависимости, поэтому цель должна заключаться в том, чтобы график зависимостей был как можно более простым и разумным.

Я предпочитаю хранить все шаблоны для проекта в рамках единого каталога шаблонов проектов, с подкаталогом для каждого приложения (использование подкаталога шаблона для каждого приложения является очень сильным соглашением в Django, поскольку оно позволяет избежать конфликтов имен шаблонов между приложениями). Причиной создания единого шаблона шаблонов проектов является то, что шаблоны, деревья наследования шаблонов и имена блоков могут быть вполне специфичными для проекта, поэтому трудно обеспечить "стандартные" шаблоны приложений, которые могут подключаться к любому проекту. Были некоторые попытки установить стандартные соглашения об именах для базовых шаблонов сайта и блоков, которые они определяют, но я еще не видел стандартного выхода (как они делают что-то в Pinax, вероятно, ближе всего к стандарту).

Re "string externalization", если вы имеете в виду i18n и l10n, Django имеет сильную поддержку для этого и стандартных мест, где он помещает файлы .po - проверьте docs.

Ответ 2

Я нашел, что макет Захари весьма полезен Блог Zachary Voases" Проекты проектов Django, Revisited.

Ответ 3

Эта страница хорошо справляется с некоторыми из моих вопросов: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

В частности:

Чтобы определить пользовательские теги или фильтры шаблонов, вы должны создать подкаталог в каталоге приложений, называемом templatetags, и он должен содержать файл с именем __init__.py, чтобы он мог быть импортирован как модуль Python.

Чтобы определить модульные тесты, которые будут автоматически замечены инфраструктурой тестирования Djangos, поместите их в модуль, называемый test (который может быть либо файлом с именем tests.py, либо каталогом, который называется test). Рамки тестирования также найдут какие-либо доктрины в этом модуле, но предпочтительным местом для них является, конечно же, docstrings классов или функций, предназначенных для тестирования.

Чтобы предоставить пользовательский SQL, который будет запущен сразу после установки вашего приложения, создайте подкаталог sql внутри каталога приложений; имена файлов должны совпадать с именами моделей, на которых они работают; например, если у вас есть приложение с именем weblog, содержащее модель с именем Entry, тогда файл sql/entry.sql внутри каталога apps может быть использован для изменения или вставки данных в таблицу записей, как только он будет создан.

Заметка о test.py и тестах (каталог) также относится к моделям, что помогает решить проблему наличия пути к множеству тестов (или моделей) для одного файла.

Мне бы хотелось увидеть некоторые примеры/предложения для разбивки на приложения/проекты и большие сайты django, которые работают хорошо.

Ответ 4

Проект Pinax основан на идее небольших приложений многократного использования, которые легко объединяются в проект. Они использовали проект Cloud 27 в качестве демонстрационного проекта.

Проект Django, над которым я работаю (называется Basie. Он до 0,1, так что ссылки еще нет.) пытается следовать модели Pinax, и до сих пор она работает довольно хорошо.

Ответ 5

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

Я создал две папки: $APP_ROOT/devel и $APP_ROOT/prod. Они содержат все приложения. Использование источника управления (в моем случае git). У меня есть приложения, разработанные в версии HEAD, а приложения в prod заблокированы для тега PROD. Шаблоны также имеют свою собственную папку с тем же расположением, что и приложения.

Теперь я могу выполнить все мои разработки в папке devel-apps и соответствующей папке-шаблоне. Когда у меня есть что-то, чему я доволен, я отмечаю эту версию и обновление prod.

Ответ 6

Мне действительно нравится Randall Degges на эту тему. Он оставляет информацию о том, как склеить файлы настроек вместе, но у меня будет сообщение о том, что я смогу связать, но на данный момент любой может проверить my repo, где я включаю какое-то направление в readme.