mirror of
https://github.com/django/django.git
synced 2024-12-23 01:25:58 +00:00
Renamed AppConfig.setup to ready.
Thanks Jannis and Marc for the feedback. Fixed #21717.
This commit is contained in:
parent
63137a8304
commit
1d23d766ab
@ -159,7 +159,7 @@ class AppConfig(object):
|
||||
models_module_name = '%s.%s' % (self.name, MODELS_MODULE_NAME)
|
||||
self.models_module = import_module(models_module_name)
|
||||
|
||||
def setup(self):
|
||||
def ready(self):
|
||||
"""
|
||||
Override this method in subclasses to run setup code.
|
||||
Override this method in subclasses to run code when Django starts.
|
||||
"""
|
||||
|
@ -105,7 +105,7 @@ class Apps(object):
|
||||
self.ready = True
|
||||
|
||||
for app_config in self.get_app_configs():
|
||||
app_config.setup()
|
||||
app_config.ready()
|
||||
|
||||
def check_ready(self):
|
||||
"""
|
||||
|
@ -175,10 +175,10 @@ Methods
|
||||
``model_name``. Raises :exc:`~exceptions.LookupError` if no such model
|
||||
exists. ``model_name`` is case-insensitive.
|
||||
|
||||
.. method:: AppConfig.setup()
|
||||
.. method:: AppConfig.ready()
|
||||
|
||||
Subclasses can override this method to perform setup tasks such as
|
||||
registering signals. It is called as soon as the registry is fully
|
||||
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
|
||||
|
@ -355,7 +355,7 @@ been defined and registered with Django's model system. Django uses this
|
||||
signal internally; it's not generally used in third-party applications.
|
||||
|
||||
Since this signal is sent during the app registry population process, and
|
||||
:meth:`AppConfig.setup() <django.apps.AppConfig.setup>` runs after the app
|
||||
:meth:`AppConfig.ready() <django.apps.AppConfig.ready>` runs after the app
|
||||
registry is fully populated, receivers cannot be connected in that method.
|
||||
One possibility is to connect them ``AppConfig.__init__()`` instead, taking
|
||||
care not to import models or trigger calls to the app registry.
|
||||
|
@ -74,7 +74,7 @@ attach configuration data to applications.
|
||||
Improvements thus far include:
|
||||
|
||||
* Applications can run code at startup, before Django does anything else, with
|
||||
the :meth:`~django.apps.AppConfig.setup` method of their configuration.
|
||||
the :meth:`~django.apps.AppConfig.ready` method of their configuration.
|
||||
|
||||
* It is possible to omit ``models.py`` entirely if an application doesn't
|
||||
have any models.
|
||||
|
@ -142,14 +142,14 @@ Now, our ``my_callback`` function will be called each time a request finishes.
|
||||
|
||||
In practice, signal handlers are usually defined in a ``signals``
|
||||
submodule of the application they relate to. Signal receivers are
|
||||
connected in the :meth:`~django.apps.AppConfig.setup` method of your
|
||||
connected in the :meth:`~django.apps.AppConfig.ready` method of your
|
||||
application configuration class. If you're using the :func:`receiver`
|
||||
decorator, simply import the ``signals`` submodule inside
|
||||
:meth:`~django.apps.AppConfig.setup`.
|
||||
:meth:`~django.apps.AppConfig.ready`.
|
||||
|
||||
.. versionchanged:: 1.7
|
||||
|
||||
Since :meth:`~django.apps.AppConfig.setup` didn't exist in previous
|
||||
Since :meth:`~django.apps.AppConfig.ready` didn't exist in previous
|
||||
versions of Django, signal registration usually happened in the
|
||||
``models`` module.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user