mirrors/django
mirrors/django
0
0
Fork 0
mirror of https://github.com/django/django.git synced 2024-12-01 15:42:04 +01:00
Code Issues Releases Wiki Activity

Changed convention for modules storing AppConfigs.

Browse Source 
The app/apps dichotomy was more confusing than valuable.
This commit is contained in:
Aymeric Augustin 2014-01-02 23:06:25 +01:00
parent 07711e9997
commit 449ede03b8
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/ref/applications.txt
View File

@ -59,7 +59,7 @@ 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
# rock_n_roll/apps.py
from django.apps import AppConfig
@ -67,11 +67,11 @@ would provide a proper name for the admin::
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`.
You would then tell your users to add ``'rock_n_roll.apps.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.
the application called ``apps``. 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