django - сайт подкаталога приложения / app1 / app2 / app3 - PullRequest
Новая
       10

django - сайт подкаталога приложения / app1 / app2 / app3

1 голос
/ 29 мая 2009

Если вы должны были написать приложение для сайта, но хотели, чтобы приложение подключалось и работало, чтобы вы могли просто добавить его в любой проект Django, установить основной URL-адрес, и все, как вы это сделаете, если хотите оставьте все другие необходимые служебные приложения включенными в ваше портативное приложение.

Пример: 

site/
site/site-app1
site/templates/site-app1
site/util-app1
site/util-app2
site/util-app3

Примечание: сайт-приложение1 использует все три утилиты-приложения. Это прекрасно работает таким образом. Но теперь вы решили отправить приложение кому-то, но только этому приложению со всеми его зависимостями.

Если бы мы могли упаковать и отправить приложения, как это?: 

site/site-app1
site/site-app1/template
site/site-app1/util-app1
site/site-app1/util-app2
site/site-app1/util-app3

Тогда вы просто отправляете site-app1, и все идет с ним.

Есть ли способ сделать переносной с помощью служебных приложений в качестве подкаталогов?

Примечание: идея в том, что мы не хотим отправлять весь проект, а одно приложение-сайт в пределах только проект.

Ответы [ 3 ]

2 голосов
/ 29 мая 2009

Было несколько презентаций о повторно используемых приложениях django, так что ищите. Это должно помочь вам:

1 голос
/ 30 мая 2009

Приложения Django можно сделать переносимыми, придерживаясь определенных практик. Конечно, это не обязательно

Расположение приложения

Соглашение состоит в том, чтобы добавлять приложения в каталог apps / и изменять файл manage.py (и, в конечном итоге, конфигурацию apache), чтобы включить 

import sys
from os.path import abspath, dirname, join
PROJECT_ROOT = abspath(dirname(__file__))
sys.path.insert(0, join(PROJECT_ROOT, "apps"))

Ваша структура каталогов будет выглядеть примерно так: 

site
site/apps/
site/apps/app1/
site/apps/app2/

Шаблоны

Шаблоны находятся в каталоге шаблонов в приложении. Соглашение не должно заставлять пользователя копировать их в любом другом месте. В конце концов, у пользователя могут быть глобальные шаблоны для переопределения шаблонов в приложении.

Настройки

Сохраните все настройки по умолчанию в локальном файле в каталоге приложения. Настройки будут переопределены глобальными настройками. Файл локальных настроек будет иметь следующую структуру. 

from django.conf import settings

def get(key, default):
    return getattr(settings, key, default)

SETTING_1 = get('SETTTING_1', 10)

Эти соглашения должны охватывать большинство основных вопросов.

1 голос
/ 30 мая 2009

Презентации @Gerry ссылки на являются хорошими источниками общей информации. Чтобы ответить на ваш вопрос более прямо , нет способа упаковать одно приложение в другое ( РЕДАКТИРОВАТЬ извините, это просто неправильно. Вы можете поместить одно приложение в пространство имен другого, и оно работает просто отлично. Но это странная вещь: вы подразумеваете, что одно приложение является частью другого, если это правда, их будет проще использовать как одно приложение. Я все еще рекомендую один из следующих вариантов). AFAICT ваши варианты:

  1. Если возможно, сделайте эти внешние зависимости необязательными (т. Е. Расширенные функциональные возможности, если util_app1 доступен, аварийное поведение, если это не так). Это то, как много приложений ведут себя, скажем, относительно django-tagging или django-mailer.

  2. Объедините все функции в одном приложении. В зависимости от того, от какого кода вы на самом деле зависите от служебных приложений, если зависимости абсолютно необходимы для работы вашего приложения, это может быть лучшим вариантом для облегчения работы ваших пользователей.

  3. Упакуйте и распространите все приложения по отдельности и обратите внимание на зависимости как в документации, так и в setup.py install_requires. Если все приложения независимо друг от друга полезны, этот подход может быть лучшим. Если они не все полезны независимо друг от друга, почему они все отдельные приложения?

...