django文档学习之applications使用详解
本文研究的主要是Django1.10文档的深入学习,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中导入应用程序注册表,应用程序的名称将与应用程序子模块冲突。最佳做法是将该代码移动到子模块并将其导入。 解决方法是以不同的名称导入注册表:
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
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使用详解的全部内容,希望对大家有所帮助。感兴趣的朋友可以继续参阅本站其他相关专题,如有不足之处,欢迎留言指出。感谢朋友们对本站的支持! 您可能感兴趣的文章:
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |