Какова цель apps.py в Django?

Этот вопрос задан ранее: Какова цель apps.py в Django 1.9?

Объекты конфигурации приложения хранят метаданные для приложения. Некоторые атрибуты могут быть настроены в подклассах AppConfig. Другие устанавливаются Django и доступны только для чтения.

Однако, что это означает метаданные для приложения? Ограничено ли оно только теми AppConfig метаданные: name, verbose_name, path, label, module, models_module?

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

# File: settings.py
BLOG = {
    'DATE_FORMAT': 'ddMMYYY',
}

В котором он используется следующим образом:

# File: blog/<...>.py
from django.conf import settings
date_format = settings.BLOG['DATE_FORMAT']

Наоборот, мы могли бы переместить эту конфигурацию в blog/apps.py как BlogConfig?

class BlogConfig(AppConfig):
    name = 'blog'
    verbose_name = 'Awesome Blog'
    date_format = 'ddMMYYYY'

Так что во всем коде приложения, date_format используется:

# File: blog/<...>.py
from django.apps import apps
date_format = apps.get_app_config('blog').date_format

Мне кажется, что settings.py - это проект, но не настройки приложения. Таким образом, больше звуков помещать все настройки приложения внутри apps.py, затем settings.py. Итак, это допустимое предположение/аргумент/соглашение для меня, чтобы добавить конфигурацию приложения внутри apps.py вместо settings.py?

ОТВЕТЫ

Ответ 1

Проект уникален для установки на django, в то время как приложение должно быть повторно использовано.

Если вы разместите пользовательские настройки приложения в своем проекте settings.py, они должны быть модифицируемыми, особенно если вы (или другие) повторно используете это приложение для другого проекта.

Теперь, если вы разместите эти пользовательские настройки в своем приложении apps.py, это означает, что они не будут модифицироваться для каждого проекта. В этом случае нет причин помещать их в apps.py, а не в подканал constants, например. Если вы не хотите предоставлять ограниченный набор возможных конфигураций:

class BlogConfig(AppConfig):
    name = 'blog'
    verbose_name = "Blog"
    date_format = 'ddMMYYYY'


class CustomizableDateFormatBlogConfig(BlogConfig):
    date_format = getattr(settings, 'BLOG_DATE_FORMAT', BlogConfig.date_format)


class I18nBlogConfig(BlogConfig)
    verbose_name = _("Blog")

default_app_config будет BlogConfig, но проект с помощью приложения сможет выбрать CustomizableDateFormatBlogConfig или I18nBlogConfig.

Однако это делает очень плохо настраиваемые приложения. В приведенном выше примере, если вы хотите, чтобы пользователи приложений использовали как CustomizableDateFormatBlogConfig, так и I18nBlogConfig, вам нужно сделать что-то вроде этого:

class BlogConfig(AppConfig):
    name = 'blog'
    verbose_name = "Blog"
    date_format = 'ddMMYYYY'


class CustomizableDateFormatMixin:
    date_format = getattr(settings, 'BLOG_DATE_FORMAT', BlogConfig.date_format)


class I18nMixin:
    verbose_name = _("Blog")


class CustomizableDateFormatBlogConfig(CustomizableDateFormatMixin, BlogConfig):
    pass


class I18nBlogConfig(I18nMixin, BlogConfig):
    pass


class I18nCustomizableDateFormatBlogConfig(I18nMixin, CustomizableDateFormatMixin, BlogConfig):
    pass

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