django文档学习之applications使用详解_Python

本文研究的主要是Django1.10文档的深入学习，Applications基础部分的相关内容，具体介绍如下。

Applications应用

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

这个注册表简单称为应用程序，它可以在django.apps中使用：

				?

									>>> from django.apps import apps

									>>> apps.get_app_config('admin').verbose_name

									'Admin'

django文档学习之applications使用详解

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