Django 1.10 Applications 应用配置详解：AppConfig 与注册表机制

本文主要探讨 Django 1.10 文档中关于 Applications（应用）基础部分的深入学习内容，具体介绍如下。

Applications 应用

Django 包含一个安装的应用程序注册表，用于存储配置并提供内省（introspection）功能。它还保留了可用模型的列表。

这个注册表简称为应用（apps），可以通过 django.apps 模块访问：

>>> from django.apps import apps
>>> apps.get_app_config('admin').verbose_name
'Admin'

Projects and applications 项目与应用程序

术语“项目”描述了一个 Django Web 应用程序。项目的 Python 包主要由设置模块定义，但通常包含其他内容。例如，当您运行 django-admin startproject mysite 时，您将得到一个 mysite 项目目录，其中包含一个具有 settings.py、urls.py 和 wsgi.py 的 mysite Python 包。项目包通常被扩展，包括与特定应用程序无关的资源，如固定装置（fixtures）、CSS 和模板等。

项目的根目录（包含 manage.py）的根目录通常是未单独安装的所有项目应用程序的容器。

术语“应用程序”描述了一个提供一些功能的 Python 包。应用程序可以在各种项目中重复使用。

应用程序包括模型、视图、模板、模板标签、静态文件、URL、中间件等的一些组合。它们通常连接到具有 INSTALLED_APPS 设置的项目中，并且可选地使用其他机制，例如 URLconfs、MIDDLEWARE 设置或模板继承。

重要的是要了解 Django 应用程序只是一组与框架的各个部分进行交互的代码。没有名为“应用程序对象”的东西。但是，Django 需要与安装的应用程序进行交互，主要用于配置和内省操作。这就是为什么应用程序注册表在每个安装的应用程序的 AppConfig 实例中维护元数据的原因。

没有限制项目包不能被认为是应用程序，并且有模型等（这将需要将其添加到 INSTALLED_APPS）。

Configuring applications 配置应用程序

要配置一个应用程序，子类化 AppConfig，并将虚线路径放在 INSTALLED_APPS 中的该子类中。

当 INSTALLED_APPS 只包含应用程序模块的虚线路径时，Django 会检查该模块中的 default_app_config 变量。

如果定义了它，那该应用程序的 AppConfig 子类的虚线路径。

如果没有 default_app_config，Django 使用基础 AppConfig 类。

default_app_config 允许早于 Django 1.7 的应用程序（如 django.contrib.admin）选择加入 AppConfig 功能，而不需要用户更新其 INSTALLED_APPS。

新的应用程序应该避免使用 default_app_config。相反，它们应该要求在 INSTALLED_APPS 中明确配置适当的 AppConfig 子类的虚线路径。

对于应用程序作者

如果您正在创建一个名为“Rock'n'roll”的可插拔应用程序，那么您将如何为管理员提供一个正确的名称：

# rock_n_roll/apps.py

from django.apps import AppConfig

class RockNRollConfig(AppConfig):
  name = 'rock_n_roll'
  verbose_name = "Rock 'n' roll"

您可以使您的应用程序默认加载此 AppConfig 子类，如下所示：

# rock_n_roll/__init__.py

default_app_config = 'rock_n_roll.apps.RockNRollConfig'

当 INSTALLED_APPS 只包含 'rock_n_roll' 时，这将导致使用 RockNRollConfig。这允许您使用 AppConfig 功能，而不需要您的用户更新其 INSTALLED_APPS 设置。除了这个用例之外，最好避免使用 default_app_config，而是如下所述在 INSTALLED_APPS 中指定 app config 类。

当然，您也可以告诉用户将“rock_n_roll.apps.RockNRollConfig”放在 INSTALLED_APPS 设置中。您甚至可以提供不同行为的几个不同的 AppConfig 子类，并允许用户通过其 INSTALLED_APPS 设置来选择一个。

推荐的约定是将配置类放在名为 apps 的应用程序的子模块中。但是，Django 并不执行此操作。

您必须包含 Django 的 name 属性，以确定此配置应用于哪个应用程序。您可以定义 AppConfig API 参考中记录的任何属性。

注意

如果您的代码在应用程序的 __init__.py 中导入应用程序注册表，应用程序的名称将与应用程序子模块冲突。最佳做法是将该代码移动到子模块并将其导入。解决方法是以不同的名称导入注册表：

from django.apps import apps as django_apps

For application users 对于应用程序用户

如果您在一个名为选集的项目中使用“Rock 'n' roll”，但您希望将其显示为“Jazz Manouche”，则可以提供自己的配置：

# anthology/apps.py

from rock_n_roll.apps import RockNRollConfig

class JazzManoucheConfig(RockNRollConfig):
  verbose_name = "Jazz Manouche"

# anthology/settings.py

INSTALLED_APPS = [
  'anthology.apps.JazzManoucheConfig',
  # ...
]

再次，在名为 apps 的子模块中定义项目特定的配置类是一个约定，而不是一个要求。

Application configuration 应用程序配置

class AppConfig[source]:

应用程序配置对象存储应用程序的元数据。一些属性可以在 AppConfig 子类中配置。其他由 Django 设置，只读。

Configurable attributes 可配置属性

AppConfig.name:

完整的 Python 路径到应用程序，例如 'django.contrib.admin'。

此属性定义配置应用于哪个应用程序。它必须在所有 AppConfig 子类中设置。

它在 Django 项目中必须是独一无二的。

AppConfig.label:

应用程序的简称，例如 'admin'

当两个应用程序具有冲突的标签时，此属性允许重新标签应用程序。它默认为名称的最后一个组件。它应该是一个有效的 Python 标识符。

它在 Django 项目中必须是独一无二的。

AppConfig.verbose_name:

应用程序的可读名称，例如“Administration”。

此属性默认为 label.title()。

AppConfig.path:

文件系统到应用程序目录的路径，例如 '/usr/lib/python3.4/dist-packages/django/contrib/admin'。

在大多数情况下，Django 可以自动检测并设置，但您也可以在 AppConfig 子类中提供显式覆盖作为类属性。在一些情况下，这是必需的;例如，如果应用程序包是具有多个路径的命名空间包。

Read-only attributes 只读属性

AppConfig.module:

应用程序的根模块，例如 'django.contrib.admin' from 'django / contrib / admin / __ init __。pyc'。

AppConfig.models_module:

包含模型的模块，例如 来自 'django / contrib / admin / models.pyc' 的 <module 'django.contrib.admin.models'。

如果应用程序不包含模型模块，则可能为 None。请注意，数据库相关信号（如 pre_migrate 和 post_migrate）仅适用于具有模型模块的应用程序。

Methods

AppConfig.get_models()[source] Returns an iterable of Model classes for this application.

AppConfig.get_model(model_name)[source] Returns the Model with the given model_name. Raises LookupError if no such model exists in this application. model_name is case-insensitive.

AppConfig.ready()[source] Subclasses can override this method to perform initialization tasks such as registering signals. It is called as soon as the registry is fully populated. Although you can't import models at the module-level where AppConfig classes are defined, you can import them in ready(), using either an import statement or get_model(). If you're registering model signals, you can refer to the sender by its string label instead of using the model class itself. Example: 在 ready() 方法中，可以通过 import 语句或 self.get_model('MyModel') 导入模型类。注册信号时，建议使用字符串标签指定 sender，例如 'app_label.MyModel'，而非直接引用模型类本身。

Although you can't import models at the module-level where AppConfig classes are defined, you can import them in ready(), using either an import statement or get_model().

If you're registering model signals, you can refer to the sender by its string label instead of using the model class itself.

Example:

from django.db.models.signals import pre_save

def ready(self):
  # importing model classes
  from .models import MyModel # or...
  MyModel = self.get_model('MyModel')

  # registering signals with the model's string label
  pre_save.connect(receiver, sender='app_label.MyModel')

总结

在我看来，对官方文档的学习是一方面，找一些不错的实例去实践一下也很重要。

以上就是本文关于 Python 文档学习之 applications 使用详解的全部内容，希望对大家有所帮助。感兴趣的朋友可以继续参阅本站其他相关专题，如有不足之处，欢迎留言指出。感谢朋友们对本站的支持！