1
0
mirror of https://github.com/django/django.git synced 2024-12-25 18:46:22 +00:00
django/docs/ref/applications.txt

220 lines
7.1 KiB
Plaintext
Raw Normal View History

============
Applications
============
.. module:: django.apps
.. versionadded:: 1.7
Django contains a registry of installed applications that stores configuration
and provides introspection. It also maintains a list of available :doc:`models
</topics/db/models>`.
This registry is simply called :attr:`~django.apps.apps` and it's available in
:mod:`django.apps`::
>>> from django.apps import apps
>>> apps.get_app_config('admin').verbose_name
'Admin'
Projects and applications
=========================
Django has historically used the term **project** to describe an installation
of Django. A project is defined primarily by a settings module.
The term **application** describes a Python package that provides some set of
features. Applications may be reused in various projects.
.. note::
This terminology is somewhat confusing these days as it became common to
use the phrase "web app" to describe what equates to a Django project.
Applications include some combination of models, views, templates, template
tags, static files, URLs, middleware, etc. They're generally wired into
projects with the :setting:`INSTALLED_APPS` setting and optionally with other
mechanisms such as URLconfs, the :setting:`MIDDLEWARE_CLASSES` setting, or
template inheritance.
It is important to understand that a Django application is just a set of code
that interacts with various parts of the framework. There's no such thing as
an ``Application`` object. However, there's a few places where Django needs to
interact with installed applications, mainly for configuration and also for
introspection. That's why the application registry maintains metadata in an
:class:`~django.apps.AppConfig` instance for each installed application.
Configuring applications
========================
To configure an application, subclass :class:`~django.apps.AppConfig` and put
the dotted path to that subclass in :setting:`INSTALLED_APPS`.
Django uses the default :class:`~django.apps.AppConfig` class when
:setting:`INSTALLED_APPS` simply contains the dotted path to an application
module.
For application authors
-----------------------
If you're creating a pluggable app called "Rock n roll", here's how you
would provide a proper name for the admin::
# rock_n_roll/app.py
from django.apps import AppConfig
class RockNRollConfig(AppConfig):
name = 'rock_n_roll'
verbose_name = "Rock n roll"
You would then tell your users to add ``'rock_n_roll.app.RockNRollConfig'`` to
their :setting:`INSTALLED_APPS`.
The recommended convention is to put the configuration class in a submodule of
the application called ``app``. However, this isn't enforced by Django.
You must include the :attr:`~django.apps.AppConfig.name` attribute for Django
to determine which application this configuration applies to. You can define
any attributes documented in the :class:`~django.apps.AppConfig` API
reference.
For application users
---------------------
If you're using "Rock n roll" in a project called ``anthology``, but you
want it to show up as "Gypsy jazz" instead, you can provide your own
configuration::
# anthology/apps.py
from rock_n_roll.app import RockNRollConfig
class GypsyJazzConfig(RockNRollConfig):
verbose_name = "Gypsy jazz"
# anthology/settings.py
INSTALLED_APPS = [
'anthology.apps.GypsyJazzConfig',
# ...
]
Again, defining project-specific configuration classes in a submodule called
``apps`` is a convention, not a requirement.
Application configuration
=========================
.. class:: AppConfig
Application configuration objects store metadata for an application. Some
attributes can be configured in :class:`~django.apps.AppConfig`
subclasses. Others are set by Django and read-only.
Configurable attributes
-----------------------
.. attribute:: AppConfig.name
Full Python path to the application, e.g. ``'django.contrib.admin'``.
This attribute defines which application the configuration applies to. It
must be set in all :class:`~django.apps.AppConfig` subclasses.
It must be unique across a Django project.
.. attribute:: AppConfig.label
Short name for the application, e.g. ``'admin'``
This attribute allows relabelling an application when two applications
have conflicting labels. It defaults to the last component of ``name``.
It should be a valid Python identifier.
It must be unique across a Django project.
.. attribute:: AppConfig.verbose_name
Human-readable name for the application, e.g. "Admin".
This attribute defaults to ``label.title()``.
Read-only attributes
--------------------
.. attribute:: AppConfig.path
Filesystem path to the application directory, e.g.
``'/usr/lib/python2.7/dist-packages/django/contrib/admin'``.
It may be ``None`` if the application isn't stored in a directory, for
instance if it's loaded from an egg.
.. attribute:: AppConfig.module
Root module for the application, e.g. ``<module 'django.contrib.admin' from
'django/contrib/admin/__init__.pyc'>``.
.. attribute:: AppConfig.models_module
Module containing the models, e.g. ``<module 'django.contrib.admin.models'
from 'django/contrib/admin/models.pyc'>``.
It may be ``None`` if the application doesn't contain a ``models`` module.
Methods
-------
2013-12-29 19:26:13 +00:00
.. method:: AppConfig.get_models()
Returns an iterable of :class:`~django.db.models.Model` classes.
.. method:: AppConfig.get_model(model_name)
Returns the :class:`~django.db.models.Model` with the given
``model_name``. Raises :exc:`~exceptions.LookupError` if no such model
exists. ``model_name`` is case-insensitive.
.. method:: AppConfig.ready()
Subclasses can override this method to perform initialization tasks such
as registering signals. It is called as soon as the registry is fully
populated.
Application registry
====================
.. data:: apps
The application registry provides the following public API. Methods that
aren't listed below are considered private and may change without notice.
.. method:: apps.ready()
Returns ``True`` if the registry is fully populated.
.. method:: apps.get_app_configs()
Returns an iterable of :class:`~django.apps.AppConfig` instances.
.. method:: apps.get_app_config(app_label)
Returns an :class:`~django.apps.AppConfig` for the application with the
given ``app_label``. Raises :exc:`~exceptions.LookupError` if no such
application exists.
.. method:: apps.has_app(app_name)
Checks whether an application with the given name exists in the registry.
``app_name`` is the full name of the app, e.g. 'django.contrib.admin'.
Unlike :meth:`~django.apps.apps.get_app_config`, this method can be called
safely at import time. If the registry is still being populated, it may
return ``False``, even though the app will become available later.
.. method:: apps.get_model(app_label, model_name)
Returns the :class:`~django.db.models.Model` with the given ``app_label``
and ``model_name``. Raises :exc:`~exceptions.LookupError` if no such
application or model exists. ``model_name`` is case-insensitive.