Все нижеописанное отностится к версии 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 arg2Windows определяем запускаемый файл по расширению, и в случае корректной установки 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 — в нем хранятся настройки интерфейса администратора приложения.
Как это все работает?
- Браузер запрашивает URL , сервер передает запрос в Django
- Django формирует объект HttpRequest
- Запускаются методы process_request Middleware-классов
- Ищет соответствия в файле urls.py
- Запускаются методы process_view Middleware-классов
- Передает Request и параметры (если таковые определены в urls.py) в найденное представление
- Выполняется функция представления, возвращается объект HttpResponse
- Запускаются методы process_response Middleware-классов
- Django передает ответ на WEB-сервер и дальше в браузер
Это сильно упрощенная версия, но вполне соответствующая действительности.
Немного о Middleware
Как видно из вышеописанного, Middleware выполняются между браузером и представлением (view) — отсюда и название. Это очень полезные классы — позволяющие модифицировать запросы и ответы: например добавить в ответ какой-нибудь заголовок, или добавить к каждому запросу поле с именем пользователя, который этот запрос осуществил (именно так работает django.contrib.auth)