Django には、設定の保存と調査の手段を提供するインストール済みアプリケーションのレジストリがあり、利用可能な モデル のリストもアクセスできます。
\nこのレジストリは単に apps と呼ばれ、次のようにして django.apps から使用できます。
>>> from django.apps import apps\n>>> apps.get_app_config('admin').verbose_name\n'Admin'\nプロジェクト (project) という単語は、Django の web アプリケーションを指します。プロジェクトの Python パッケージは主に settings モジュールで定義されますが、通常は他のファイルも含まれます。たとえば、 django-admin startproject mysite を実行すると、mysite プロジェクトディレクトリが作成され、その中には settings.py、urls.py、wsgi.py などのファイルが含まれる mysite Python パッケージが作られます。プロジェクトパッケージは、fixture や CSS、テンプレートなど特定のアプリケーションに束縛されないファイルも含まれることがふつうです。
プロジェクトのルートディレクトリ (manage.py があるディレクトリ) は、プロジェクトと一緒にインストールされるすべてのアプリケーションのコンテナとして機能します。
アプリケーション (application) という言葉は、いくつかの機能を提供する Python パッケージを意味します。アプリケーションはさまざまなプロジェクトで 再利用する ことができます。
\nアプリケーションには、モデル、ビュー、テンプレート、テンプレートタグ、スタティックファイル、ミドルウェアなどが含まれます。これらは一般に INSTALLED_APPS 設定で有効になり、それ以外では URLconfs、 MIDDLEWARE 設定、テンプレート継承などの仕組みから使われます。
Django のアプリケーションは、フレームワークのさまざまなパーツとやりとりをする単なるコードの集まりであると理解するのは大切です。Application オブジェクトのようなものは存在しません。しかしながら、Django がインストール済みのアプリケーションの主に設定やイントロスペクションとやりとりをする必要があることもあります。そのため、インストールアプリケーションごとのメタデータは、アプリケーションレジストリが AppConfig インスタンス内に保存しています。
There's no restriction that a project package can't also be considered an\napplication and have models, etc. (which would require adding it to\nINSTALLED_APPS).
アプリケーションを設定するには、 AppConfig のサブクラスを作り、そのサブクラスへのドット区切りのパスを INSTALLED_APPS に追加します。
INSTALLED_APPS にアプリケーションモジュールを指すドット区切りのパスがある場合、Django はそのモジュールの default_app_config 変数をチェックします。
もしこの変数が定義されていれば、そのドット区切りのパスがアプリケーション AppConfig サブクラスになります。
もし default_app_config が定義されていなければ、Django は ベースとなる AppConfig クラスを使用します。
default_app_config allows applications that predate Django 1.7 such as\ndjango.contrib.admin to opt-in to AppConfig features\nwithout requiring users to update their INSTALLED_APPS.
New applications should avoid default_app_config. Instead they should\nrequire the dotted path to the appropriate AppConfig\nsubclass to be configured explicitly in INSTALLED_APPS.
If you're using "Rock ’n’ roll" in a project called anthology, but you\nwant it to show up as "Jazz Manouche" instead, you can provide your own\nconfiguration:
# anthology/apps.py\n\nfrom rock_n_roll.apps import RockNRollConfig\n\nclass JazzManoucheConfig(RockNRollConfig):\n verbose_name = "Jazz Manouche"\n\n# anthology/settings.py\n\nINSTALLED_APPS = [\n 'anthology.apps.JazzManoucheConfig',\n # ...\n]\nAgain, defining project-specific configuration classes in a submodule called\napps is a convention, not a requirement.
Application configuration objects store metadata for an application. Some\nattributes can be configured in AppConfig\nsubclasses. Others are set by Django and read-only.
Full Python path to the application, e.g. 'django.contrib.admin'.
This attribute defines which application the configuration applies to. It\nmust be set in all AppConfig subclasses.
Djangoプロジェクト全体の中で固有である必要があります。
\nShort name for the application, e.g. 'admin'
This attribute allows relabeling an application when two applications\nhave conflicting labels. It defaults to the last component of name.\nIt should be a valid Python identifier.
Djangoプロジェクト全体の中で固有である必要があります。
\nHuman-readable name for the application, e.g. "Administration".
\nThis attribute defaults to label.title().
Filesystem path to the application directory, e.g.\n'/usr/lib/python3.4/dist-packages/django/contrib/admin'.
In most cases, Django can automatically detect and set this, but you can\nalso provide an explicit override as a class attribute on your\nAppConfig subclass. In a few situations this is\nrequired; for instance if the app package is a namespace package with\nmultiple paths.
Root module for the application, e.g. <module 'django.contrib.admin' from\n'django/contrib/admin/__init__.pyc'>.
Module containing the models, e.g. <module 'django.contrib.admin.models'\nfrom 'django/contrib/admin/models.pyc'>.
It may be None if the application doesn't contain a models module.\nNote that the database related signals such as\npre_migrate and\npost_migrate\nare only emitted for applications that have a models module.
Returns an iterable of Model classes for this\napplication.
Returns the Model with the given\nmodel_name. Raises LookupError if no such model exists in this\napplication. model_name is case-insensitive.
Subclasses can override this method to perform initialization tasks such\nas registering signals. It is called as soon as the registry is fully\npopulated.
\nAlthough you can't import models at the module-level where\nAppConfig classes are defined, you can import them in\nready(), using either an import statement or\nget_model().
If you're registering model signals, you\ncan refer to the sender by its string label instead of using the model\nclass itself.
実装例:
\nfrom django.db.models.signals import pre_save\n\ndef ready(self):\n # importing model classes\n from .models import MyModel # or...\n MyModel = self.get_model('MyModel')\n\n # registering signals with the model's string label\n pre_save.connect(receiver, sender='app_label.MyModel')\nPython versions 3.3 and later support Python packages without an\n__init__.py file. These packages are known as "namespace packages" and may\nbe spread across multiple directories at different locations on sys.path\n(see PEP 420).
Django applications require a single base filesystem path where Django\n(depending on configuration) will search for templates, static assets,\netc. Thus, namespace packages may only be Django applications if one of the\nfollowing is true:
\nThe namespace package actually has only a single location (i.e. is not\nspread across more than one directory.)
The AppConfig class used to configure the application\nhas a path class attribute, which is the\nabsolute directory path Django will use as the single base path for the\napplication.
If neither of these conditions is met, Django will raise\nImproperlyConfigured.
The application registry provides the following public API. Methods that\naren't listed below are considered private and may change without notice.
\nBoolean attribute that is set to True after the registry is fully\npopulated and all AppConfig.ready() methods are called.
Returns an iterable of AppConfig instances.
Returns an AppConfig for the application with the\ngiven app_label. Raises LookupError if no such application\nexists.
Checks whether an application with the given name exists in the registry.\napp_name is the full name of the app, e.g. 'django.contrib.admin'.
Returns the Model with the given app_label\nand model_name. As a shortcut, this method also accepts a single\nargument in the form app_label.model_name. model_name is\ncase-insensitive.
Raises LookupError if no such application or model exists. Raises\nValueError when called with a single argument that doesn't contain\nexactly one dot.
When Django starts, django.setup() is responsible for populating the\napplication registry.
Configures Django by:
\nLoading the settings.
Setting up logging.
If set_prefix is True, setting the URL resolver script prefix to\nFORCE_SCRIPT_NAME if defined, or / otherwise.
Initializing the application registry.
This function is called automatically:
\nWhen running an HTTP server via Django's WSGI support.
When invoking a management command.
It must be called explicitly in other cases, for instance in plain Python\nscripts.
\nThe application registry is initialized in three stages. At each stage, Django\nprocesses all applications in the order of INSTALLED_APPS.
First Django imports each item in INSTALLED_APPS.
If it's an application configuration class, Django imports the root package\nof the application, defined by its name attribute. If\nit's a Python package, Django creates a default application configuration.
At this stage, your code shouldn't import any models!
\nIn other words, your applications' root packages and the modules that\ndefine your application configuration classes shouldn't import any models,\neven indirectly.
\nStrictly speaking, Django allows importing models once their application\nconfiguration is loaded. However, in order to avoid needless constraints on\nthe order of INSTALLED_APPS, it's strongly recommended not\nimport any models at this stage.
Once this stage completes, APIs that operate on application configurations\nsuch as get_app_config() become usable.
Then Django attempts to import the models submodule of each application,\nif there is one.
You must define or import all models in your application's models.py or\nmodels/__init__.py. Otherwise, the application registry may not be fully\npopulated at this point, which could cause the ORM to malfunction.
Once this stage completes, APIs that operate on models such as\nget_model() become usable.
Finally Django runs the ready() method of each application\nconfiguration.
Here are some common problems that you may encounter during initialization:
\nAppRegistryNotReady: This happens when\nimporting an application configuration or a models module triggers code that\ndepends on the app registry.
For example, ugettext() uses the app\nregistry to look up translation catalogs in applications. To translate at\nimport time, you need ugettext_lazy()\ninstead. (Using ugettext() would be a bug,\nbecause the translation would happen at import time, rather than at each\nrequest depending on the active language.)
Executing database queries with the ORM at import time in models modules\nwill also trigger this exception. The ORM cannot function properly until all\nmodels are available.
\nAnother common culprit is django.contrib.auth.get_user_model(). Use\nthe AUTH_USER_MODEL setting to reference the User model at import\ntime.
This exception also happens if you forget to call django.setup() in\na standalone Python script.
ImportError: cannot import name ... This happens if the import sequence\nends up in a loop.
To eliminate such problems, you should minimize dependencies between your\nmodels modules and do as little work as possible at import time. To avoid\nexecuting code at import time, you can move it into a function and cache its\nresults. The code will be executed when you first need its results. This\nconcept is known as "lazy evaluation".
\ndjango.contrib.admin automatically performs autodiscovery of admin\nmodules in installed applications. To prevent it, change your\nINSTALLED_APPS to contain\n'django.contrib.admin.apps.SimpleAdminConfig' instead of\n'django.contrib.admin'.