Django. Структура проекта.

Все нижеописанное отностится к версии django-1.4, в 1.3 и ниже есть некоторые отличия.

Основная причина недоумения и непонимания людей всю жизнь видевших только PHP фреймворки в как раз в структуре проекта и принципах работы фреймворка Django. Я надеюсь после прочтения туман рассеется и ориентироваться станет много проще.

Создание любого проекта Django начинается с команды

django-admin.py startproject first

где first — имя проекта, это внутреннее имя, так будет называть папка с проектом и python-package соответствующие ограничения на имя — без пробелов, только буквы-цифры, а так же имя проекта не должно конфликтовать с названиями python-модулей, вроде test, io, sys итд.

Результатом выполениния команды будет папка first в текущей директории, с неким набором вложенных папкок и файлов. Рассмотрим подробнее:

./first
├── first
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
└── manage.py

В корне проекта видим один файл — manage.py — название всегда одинаковое. Это скрипт для управление проектом, все остальные действия над проектом выполняются исключительно с его помощью: добавление новых приложений, сборка статичных файлов итд.
И папку first (точнее даже python-package) с несколькими файлами. В ней хранятся все настройки проекта.
__init__.py — пустой, и нужен только для того, чтобы python определял директорию как пакет.
settings.py — глобальные настройки проекта. Здесь настраивается почти всё — пути, базы данных, подключенные приложения, middleware итд
urls.py — файл привязок URL. Именно он отвечает, за то, что по такому-то урлу будет вызываться такой-то скрипт.
wsgi.py — WSGI приложение для взаимодействия с WEB-сервером.

При работе с POSIX-системами, для удобства можно поменить manage.py как исполняемый: chmod +x manage.py. Для краткости я буду считать его исполняемым, и запускать соответственно:

$ ./manage.py arg1 arg2

это же действие можно сделать с указанием интерпретатора:

$ python manage.py arg1 arg2

Windows определяем запускаемый файл по расширению, и в случае корректной установки Python так же будет без проблем запускать manage.py

Теперь создадим приложение с названием main:

./manage.py startapp main

посмотрим структуру проекта, она изменилась:

first
├── first
│   ├── __init__.py
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── main
│   ├── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
└── manage.py

добавилась папка (точнее python-package, поскольку так же наличиствует __init__.py) main несколькими файлами.
Рассмотрим подробнее:
models.py — файл хранит модели данного приложения.
tests.py — тесты, об этом нужен отдельный разговор.
views.py — представления данного приложения.

Автоматически не создается, но имеет место быть еще один файлик:
admin.py — в нем хранятся настройки интерфейса администратора приложения.

Как это все работает?

  1. Браузер запрашивает URL , сервер передает запрос в Django
  2. Django формирует объект HttpRequest
  3. Запускаются методы process_request Middleware-классов
  4. Ищет соответствия в файле urls.py
  5. Запускаются методы process_view Middleware-классов
  6. Передает Request и параметры (если таковые определены в urls.py) в найденное представление
  7. Выполняется функция представления, возвращается объект HttpResponse
  8. Запускаются методы process_response Middleware-классов
  9. Django передает ответ на WEB-сервер и дальше в браузер

Это сильно упрощенная версия, но вполне соответствующая действительности.

Немного о Middleware
Как видно из вышеописанного, Middleware выполняются между браузером и представлением (view) — отсюда и название. Это очень полезные классы — позволяющие модифицировать запросы и ответы: например добавить в ответ какой-нибудь заголовок, или добавить к каждому запросу поле с именем пользователя, который этот запрос осуществил (именно так работает django.contrib.auth)

Запускаем сервер и пишем первое представление