Django 1.4 nowa struktura folderów projektu wymusza prefiksy projektów?

Question

Korzystanie z django 1.4 i widziałem, że kiedy używasz startproject, teraz tworzy on folder w twoim projekcie o tej samej nazwie.

-myproject/ 
      manage.py 
      myproject/ 
        settings.py 
        urls.py 

Documented change here

Wcześniej do moich adresów URL mogłem wejście

ROOT_URLCONF = 'urls' 

Ale to już nie działa. Czy mam teraz poprzedzić to nazwą projektu? tj

ROOT_URLCONF = 'myproject.urls' 

- W moim urls.py Chciałbym importować ustawienia, ale teraz muszę poprzedzić je from myproject import settings.

Myślałem, że zmienne prefiksujące o nazwie projektu były niezgodne ze standardami django, ponieważ naruszają możliwość ponownego wykorzystania?

Answer 1

Tak, prefiks ROOT_URLCONF z nazwą projektu:

ROOT_URLCONF = 'myproject.urls' 

Nie należy importować ustawień bezpośrednio w każdym razie (patrz Using settings in Python code). Zamiast tego użyj poniższego, który działa zarówno w starym, jak i nowym układzie projektu.

from django.conf import settings 

Answer 2

Chciałbym tylko dodać, że zmusza do wykorzystania prefiksów kiedy accces głównego myproject.urls, ale nie zmusza Cię albo drogę dla swoich aplikacji. Można wybrać aplikacje do przechowywania zarówno w folderze najwyższego poziomu:

myproject 
|-- manage.py 
|-- myproject 
| |-- __init__.py 
| |-- settings.py 
| |-- urls.py 
| `-- wsgi.py 
`-- polls 
    |-- __init__.py 
    |-- models.py 
    |-- tests.py 
    `-- views.py 

Jest to domyślny podczas korzystania python manage.py startapp polls W tym przypadku byłoby użyć from polls.models import Whatever

Alternatywnie można:

mkdir myproject/polls 
python manage.py startapp polls myproject/polls 

a dostaniesz to:

myproject 
|-- manage.py 
`-- myproject 
    |-- __init__.py 
    |-- polls 
    | |-- __init__.py 
    | |-- models.py 
    | |-- tests.py 
    | `-- views.py 
    |-- settings.py 
    |-- urls.py 
    `-- wsgi.py 

W takim przypadku musisz from myproject.polls.models import Whatever ...

Tak więc pierwsze jest lepsze dla aplikacji, które Twoim zdaniem mogą być ponownie wykorzystane w innych projektach, a drugie jest lepsze dla aplikacji ściśle powiązanych z inne części twojego projektu.