Вопросы Теги

Большое расположение приложения Django

Используйте exp.printStackTrace() для отображения стека вашего исключения. 

try {
   int zero = 1 - 1;
   int a = 1/zero;
} catch (Exception e) {
    e.printStackTrace();
}
25
задан Rob Golding 19 April 2010 в 19:02
поделиться

3 ответа

Лучший способ, который я нашел для этого, - это создание приложений, а затем проект их склеивания. Большинство моих проектов имеют похожие приложения, которые включены в каждый. Электронная почта, заметки, напоминания о действиях, авторизация пользователя и т. Д. Мой предпочтительный макет выглядит примерно так:

  • project /
    • settings.py
    • urls.py
    • views.py
    • ...
  • apps /
    • электронные письма /
      • urls.py
      • views.py
      • ...
      • notes /
        • urls.py
        • views.py
        • ...
        • ...

      apps:

      Каждое из «приложений» стоит само по себе и, кроме settings.py, не зависит от сам проект (хотя он может полагаться на другие приложения). Одним из приложений является аутентификация и управление пользователями. Он имеет все URL для выполнения своих задач в apps/auth/urls.py. Все его шаблоны находятся в apps/auth/templates/auth/. Вся его функциональность автономна, поэтому, когда мне нужно что-то настроить, я знаю, куда идти.

      проект:

      project/ содержит весь клей, необходимый для объединения этих отдельных приложений в окончательный проект. В моем случае я использовал settings.INSTALLED_APPS в project/, чтобы понять, какие виды из приложений были доступны для меня. Таким образом, если я возьму apps.notes из своего INSTALLED_APPS, все по-прежнему работает чудесно, просто без заметок.

      Техническое обслуживание:

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

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

31
ответ дан Jack M. 28 November 2019 в 21:18
поделиться

Вы можете извлечь общую функциональность в отдельный модуль и сделать так, чтобы ваши приложения зависели от него:

  • my_portal
  • auth_module
  • profile_module
  • application1 (зависит от auth_module)
  • application2 (зависит от auth_module и profile_module)

Мне кажется, тот факт, что «классический» проект Django «содержит» приложения, которые он использует помешать вам увидеть картину - на самом деле, это не обязательно. Для проекта, в котором у вас будут какие-то подключаемые модули, я бы предложил организовать приложения в виде яиц и использовать zc.buildout + djangorecipe для управления всем.

Таким образом, вы сможете сохранить ваши модули в плоской одноуровневой структуре. Яйца имеют возможность указывать зависимости, поэтому, если вы установите application1 (см. Выше), auth_module будет установлен автоматически.

Также будет легко развернуть разные конфигурации на разных серверах. Предположим, у вас есть server1, на котором установлено application1, и server2, на котором установлены и application1, и application2 - вы можете просто иметь две конфигурации:

server1.cfg: 

[buildout]
extends = base_deployment.cfg
eggs += application1

server2.cfg: 

[buildout]
extends = base_seployment.cfg
eggs += application1
        application2

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

Не говоря уже о том, что у вас также может быть отдельная конфигурация для конфигурации разработки (например, с установленными debug = True и Django Debug Toolbar).

4
ответ дан Sergey 28 November 2019 в 21:18
поделиться

Вам следует взглянуть на:

Я обычно использую эту структуру проекта:

  • / djangoproject {{1} }
    • / apps
      • / main # основной код
      • / static # каждое подчиненное приложение может обрабатывать статику
      • / app1
      • / static # каждое подчиненное приложение может обслуживать статику
      • / app2 ...
    • / scripts # manage.py, wsgi, apache.conf, fabfile.py ...
    • / core # ваши библиотеки ...
    • settings.py
    • local_settings.py

Каждое приложение в / apps имеет urls.py, который автоматически включается в основной urls.py. И каждое приложение может быть подмодулем git (или svn external)

. Кроме того, с помощью git вы можете работать с разными ветвями параллелей (master / dev / customerA / customerB ...) и объединять обновления.

Создать настоящие файлы многократного использования с django не так-то просто.

4
ответ дан 28 November 2019 в 21:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: