test0908
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Changed convention for modules storing AppConfigs. 

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 If you're creating a pluggable app called "Rock ’n’ roll", here's how you
would provide a proper name for the admin:: would provide a proper name for the admin::
# rock_n_roll/app.py # rock_n_roll/apps.py
from django.apps import AppConfig from django.apps import AppConfig
@ -67,11 +67,11 @@ would provide a proper name for the admin::
name = 'rock_n_roll' name = 'rock_n_roll'
verbose_name = "Rock ’n’ roll" verbose_name = "Rock ’n’ roll"
You would then tell your users to add ``'rock_n_roll.app.RockNRollConfig'`` to You would then tell your users to add ``'rock_n_roll.apps.RockNRollConfig'``
their :setting:`INSTALLED_APPS`. to their :setting:`INSTALLED_APPS`.
The recommended convention is to put the configuration class in a submodule of 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 You must include the :attr:`~django.apps.AppConfig.name` attribute for Django
to determine which application this configuration applies to. You can define to determine which application this configuration applies to. You can define