基于 Django1.10 文档的深入学习（25）—— Applications 之 基础部分

Applications应用

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

这个注册表简单称为应用程序，它可以在

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包

。项目包通常被扩展到包括与特定应用程序无关的诸如固定装置，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

只包含

'rockphasroll'

时，这将导致使用

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:

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')