Проект Django представляет собой группу отдельных приложений, совместная работа которых обеспечивает работу проекта в целом. Пока мы создадим одно приложение, которое будет выполнять бульшую часть работы в нашем проекте. Другое приложение для управления учетными записями пользователей будет добавлено в главе 19.
К этому моменту команда runserver должна продолжать работу в терминальном окне, которое вы открыли ранее. Откройте новое терминальное окно (или вкладку) и перейдите в каталог, содержащий manage.py. Активизируйте виртуальную среду и выполните команду startapp:
learning_log$ source ll_env/bin/activate
(ll_env)learning_log$ python manage.py startapp learning_logs
(1) (ll_env)learning_log$ ls
db.sqlite3 learning_log learning_logs ll_env manage.py
(2)(ll_env)learning_log$ ls learning_logs/
admin.py __init__.py migrations models.py tests.py views.py
Команда startapp имя_приложения приказывает Django создать инфраструктуру, необходимую для построения приложения. Заглянув сейчас в каталог проекта, вы найдете в нем новый подкаталог с именем learning_logs (1) . Откройте этот каталог, чтобы увидеть, какие файлы были созданы Django (2). Самые важные файлы в этом каталоге — models.py, admin.py и views.py.
Мы воспользуемся файлом models.py для определения данных, которыми нужно управлять в нашем приложении. К файлам admin.py и views.py мы вернемся позднее.
Определение моделей
Ненадолго задумаемся, какие данные нам понадобятся. Каждый пользователь создает набор тем в своем журнале. Каждая запись, которую он сделает, будет привязана к определенной теме, а записи будут выводиться в текстовом виде. Также необходимо хранить временну?ю метку каждой записи, чтобы пользователь знал, когда эта запись была создана.
Откройте файл models.py и просмотрите его текущее содержимое:
models.py
from django.db import models
# Создайте здесь свои модели.
Модуль с именем models импортируется автоматически, и нам предлагается создать свои модели. Модель сообщает Django, как работать с данными, которые будут храниться в приложении. С точки зрения кода модель представляет собой обычный класс; она содержит атрибуты и методы, как и все остальные классы, рассматривавшиеся нами ранее. Вот как выглядит модель тем обсуждения, которые будут сохраняться пользователями:
from django.db import models
class Topic(models.Model):
. ."""Тема, которую изучает пользователь"""
(1) . .text = models.CharField(max_length=200)
(2) . .date_added = models.DateTimeField(auto_now_add=True)
(3) . .def __str__(self):
. . . ."""Возвращает строковое представление модели."""
. . . .return self.text
Мы создали класс с именем Topic, наследующий от Model — родительского класса, включенного в Django и определяющего базовую функциональность модели. Класс Topic содержит всего два атрибута: text и date_added.
Атрибут text содержит данные CharField — блок данных, состоящий из символов, то есть текст (1) . Атрибуты CharField могут использоваться для хранения небольших объемов текста: имен, заголовков, названий городов и т.д. При определении атрибута CharField необходимо сообщить Django, сколько места нужно зарезервировать для него в базе данных. В данном случае задается максимальная длина max_length, равная 200 символам; этого должно быть достаточно для хранения большинства имен тем.
Атрибут date_added содержит данные DateTimeField — блок данных для хранения даты и времени (2). Аргумент auto_add_now=True приказывает Django автоматически присвоить этому атрибуту текущую дату и время каждый раз, когда пользователь создает новую тему.
Примечание
Полный список всех полей, которые могут использоваться в модели, приведены в документе Django Model Field Reference по адресу https://docs.djangoproject.com/en/1.8/ref/models/fields/. Возможно, вся эта информация вам сейчас не понадобится, но она будет в высшей степени полезной, когда вы начнете разрабатывать собственные приложения.
Необходимо сообщить Django, какой атрибут должен использоваться по умолчанию при вводе информации о теме. Django вызывает метод __str__() для вывода простого представления модели. Мы написали реализацию __str__(), которая возвращает строку, хранящуюся в атрибуте text (3).
Примечание
Если вы используете Python 2.7, метод __str__() должен называться __unicode__(). Тело метода остается неизменным.
Активизация моделей
Чтобы использовать модели, необходимо приказать Django включить приложение в общий проект. Откройте файл settings.py (из каталога learning_log/learning_log) и найдите в нем раздел, который сообщает Django, какие приложения установлены в проекте:
settings.py
...
INSTALLED_APPS = (
. .'django.contrib.admin',
. .'django.contrib.auth',
. .'django.contrib.contenttypes',
. .'django.contrib.sessions',
. .'django.contrib.messages',
. .'django.contrib.staticfiles',
)
...
Это обычный кортеж, который сообщает Django, какие приложения образуют проект. Добавьте наше приложение в этот кортеж; измените содержимое INSTALLED_APPS, чтобы оно выглядело так:
...
INSTALLED_APPS = (
...
'django.contrib.staticfiles',
. .
. .# Мои приложения
. .'learning_logs',
)
...
Группировка приложений в проекте упрощает управление ими по мере того, как проект растет, а количество приложений увеличивается. Здесь мы создаем раздел, который пока содержит только приложение learning_logs.
Затем необходимо приказать Django изменить базу данных для хранения информации, относящейся к модели Topic. В терминальном окне введите следующую команду:
(ll_env)learning_log$ python manage.py makemigrations learning_logs
Migrations for 'learning_logs':
0001_initial.py:
. .- Create model Topic
(ll_env)learning_log$
По команде makemigrations Django определяет, как изменить базу данных для хранения информации, связанной с новыми моделями. Из результатов видно, что Django создает файл миграции с именем 0001_initial.py. Эта миграция создает в базе данных таблицу для модели Topic.
Теперь применим миграцию для автоматического изменения базы данных:
(ll_env)learning_log$ python manage.py migrate
...
Running migrations:
Rendering model states... DONE
(1) Applying learning_logs.0001_initial... OK
Бульшая часть вывода этой команды совпадает с выводом, полученным при первом выполнении команды migrate. Обратить внимание следует на строку (1) ; здесь Django подтверждает, что применение миграции для learning_logs прошло успешно.
Каждый раз, когда вы захотите изменить данные, которыми управляет Learning Log, выполните эти три действия: внесите изменения в models.py, вызовите makemigrations для learning_logs и прикажите Django выполнить миграцию проекта (migrate).
Административный сайт Django
Django позволяет легко работать с моделями, определенными для приложения, через административный сайт. Этот сайт используется администраторами сайта, а не рядовыми пользователями. В этом разделе мы создадим административный сайт и используем его для добавления некоторых тем через модель Topic.
Создание суперпользователя
Django позволяет создать пользователя, обладающего полным набором привилегий на сайте; такой пользователь называется суперпользователем. Привилегии управляют действиями, которые разрешено выполнять пользователю. На самом жестком уровне привилегий пользователь может только читать общедоступную информацию на сайте. Зарегистрированным пользователям обычно предоставляется привилегия чтения своих приватных данных, а также избранной информации, доступной только для участников сообщества. Для эффективного администрирования веб-приложения владельцу сайта обычно должна быть доступна вся информация, хранящаяся на сайте. Хороший администратор внимательно относится к конфиденциальной информации пользователя, потому что пользователи доверяют тем приложениям, с которыми они работают.
Чтобы создать суперпользователя в Django, введите следующую команду и ответьте на запросы:
(ll_env)learning_log$ python manage.py createsuperuser
(1) Username (leave blank to use 'ehmatthes'): ll_admin
(2)Email address:
(3)Password:
Password (again):
Superuser created successfully.
(ll_env)learning_log$
При получении команды createsuperuser Django предлагает ввести имя пользователя, который является суперпользователем (1) . Здесь мы вводим имя ll_admin, но вы можете ввести любое имя на свое усмотрение. Также можно ввести адрес электронной почты или оставить это поле пустым (2). После этого следует дважды ввести пароль (3).
Примечание
Часть конфиденциальной информации может быть скрыта от администраторов сайта. Например, Django на самом деле не сохраняет введенный пароль; вместо этого сохраняется хеш — специальная строка, построенная на основе пароля. И когда в будущем вы вводите пароль, Django снова хеширует введенные данные и сравнивает результат с хранимым хешем. Если два хеша совпадают, то проверка пройдена. Если же хакер в результате атаки получит доступ к базе данных сайта, он сможет прочитать только хранящийся в базе хеш, но не пароли. При правильной настройке сайта восстановить исходные пароли из хешей почти невозможно.
Регистрация модели на административном сайте
Django добавляет некоторые модели (например, User и Group) на административный сайт автоматически, но модели, которые мы создали, придется регистрировать вручную.
При запуске приложения learning_logs Django создает файл admin.py в одном каталоге с models.py:
admin.py
from django.contrib import admin
# Зарегистрируйте здесь ваши модели.
Чтобы зарегистрировать Topic на административном сайте, введите следующую команду:
from django.contrib import admin
(1) from learning_logs.models import Topic
(2)admin.site.register(Topic)
Этот код импортирует модель Topic (1) , после чего использует вызов admin.site.register() (2), регистрирующий модель для управления через административный сайт.
Теперь используйте учетную запись суперпользователя для входа на административный сайт. Введите адрес http://localhost:8000/admin/, введите имя пользователя и пароль для только что созданного суперпользователя, и вы увидите экран наподобие изображенного на рис. 18.2. На этой странице можно добавлять новых пользователей и группы, а также вносить изменения в уже существующие настройки. Помимо этого можно работать с данными, связанными с только что определенной моделью Topic.
Рис. 18.2. Административный сайт с включением модели Topic
Примечание
Если в браузере появляется сообщение о недоступности веб-страницы, убедитесь в том, что сервер Django работает в терминальном окне. Если сервер не работает, активизируйте виртуальную среду и снова введите команду python manage.py runserver.
Добавление тем
Когда модель Topic зарегистрирована на административном сайте, добавим первую тему. Щелкните на ссылке Topics, чтобы перейти к странице Topics; страница практически пуста, потому что еще нет ни одной темы для выполнения операций. Щелкните на ссылке Add; открывается форма для добавления новой темы. Введите в первом поле текст Chess и щелкните на ссылке Save. Вы возвращаетесь к административной странице Topics, на которой появляется только что созданная тема.
Создадим вторую тему, чтобы у вас было больше данных для работы. Снова щелкните на ссылке Add и создайте вторую тему Rock Climbing. Ссылка Save снова возвращает вас к основной странице Topics, где отображаются обе темы, Chess и Rock Climbing.
Определение модели Entry
Чтобы сохранить информацию о том, что вы узнали по этим двум темам, необходимо определить модель для записей, которые пользователь делает в своих журналах. Каждая запись должна ассоциироваться с конкретной темой. Такое отношение называется отношением «многие-к-одному», поскольку многие записи могут быть связаны с одной темой.
Код модели Entry выглядит так:
models.py
from django.db import models
class Topic(models.Model):
. ....
(1) class Entry(models.Model):
. ."""Информация, изученная пользователем по теме"""
(2) . .topic = models.ForeignKey(Topic)
(3) . .text = models.TextField()
. .date_added = models.DateTimeField(auto_now_add=True)
. .
(4) . .class Meta:
. . . .verbose_name_plural = 'entries'
. .def __str__(self):
. . . ."""Возвращает строковое представление модели."""
(5) . . . .return self.text[:50] + "..."
Класс Entry наследует от базового класса Model, как и рассмотренный ранее класс Topic (1) . Первый атрибут, topic, является экземпляром ForeignKey (2). Термин «внешний ключ» (foreign key) происходит из теории баз данных; внешний ключ содержит ссылку на другую запись в базе данных. Таким образом каждая запись связывается с конкретной темой. Каждой теме при создании присваивается ключ, или идентификатор. Если потребуется установить связь между двумя записями данных, Django использует ключ, связанный с каждым блоком информации. Вскоре мы используем такие связи для получения всех записей, связанных с заданной темой.
Затем идет атрибут с именем text, который является экземпляром TextField (3). Полю такого типа ограничение размера не требуется, потому что размер отдельных записей не ограничивается. Атрибут date_added позволяет отображать записи в порядке их создания и снабдить каждую запись временной меткой.
В точке (4) класс Meta вкладывается в класс Entry. Класс Meta хранит дополнительную информацию по управлению моделью; в данном случае он позволяет задать специальный атрибут, который приказывает Django использовать форму множественного числа Entries при обращении более чем к одной записи. (Без этого Django будет использовать неправильную форму Entrys.) Наконец, метод __str__() сообщает Django, какая информация должна отображаться при обращении к отдельным записям. Так как запись может быть достаточно длинным блоком текста, мы приказываем Django выводить только первые 50 символов (5). Также добавляется многоточие — признак вывода неполного текста.
Миграция модели Entry
Так как мы добавили новую модель, миграцию базы данных необходимо провести снова. Вскоре вы привыкнете к этому процессу: вы изменяете models.py, выполняете команду python manage.py makemigrations имя_приложения, а затем команду python manage.py migrate.
Проведите миграцию базы данных и проверьте вывод:
(ll_env)learning_log$ python manage.py makemigrations learning_logs
Migrations for 'learning_logs':
(1) 0002_entry.py:
. .- Create model Entry
(ll_env)learning_log$ python manage.py migrate
Operations to perform:
...
(2) Applying learning_logs.0002_entry... OK
Команда генерирует новую миграцию с именем 0002_entry.py, которая сообщает Django, как изменить базу данных для хранения информации, связанной с моделью Entry (1) . При выдаче команды migrate Django подтверждает, что применение миграции прошло успешно (2).
Регистрация Entry на административном сайте
Модель Entry тоже необходимо зарегистрировать. Файл admin.py должен выглядеть так:
admin.py
from django.contrib import admin
from learning_logs.models import Topic, Entry
admin.site.register(Topic)
admin.site.register(Entry)
Вернитесь на страницу http://localhost/admin/, и вы увидите раздел Entries в категории learning_logs. Щелкните на ссылке Add для Entries или щелкните на Entries и выберите вариант Add. На экране должен появиться раскрывающийся список для выбора темы, для которой создается запись, и текстовое поле для ввода записи. Выберите в раскрывающемся списке вариант Chess и добавьте запись. При выборе ссылки Save вы вернетесь к основной административной странице. Здесь проявляются преимущества использования формата text[:50] в качестве строкового представления каждой записи; работать с несколькими записями в административном интерфейсе намного удобнее, если вы видите только часть записи вместо ее полного текста.
Создайте вторую запись для темы Chess и одну запись для темы Rock Climbing, чтобы у нас были исходные данные для дальнейшей разработки Learning Log.
Интерактивная оболочка Django
Введенные данные можно проанализировать на программном уровне в интерактивном терминальном сеансе. Эта интерактивная среда, называемая оболочкой (shell) Django, прекрасно подходит для тестирования и диагностики проекта. Пример сеанса в интерактивной оболочке:
(ll_env)learning_log$ python manage.py shell
(1) >>>from learning_logs.models import Topic
>>>Topic.objects.all()
[
Команда python manage.py shell (выполняемая в активной виртуальной среде) запускает интерпретатор Python, который может использоваться для работы с информацией в базе данных проекта. В данном случае мы импортируем модель Topic из модуля learning_logs.models (1) . Затем метод Topic.objects.all() используется для получения всех экземпляров модели Topic; возвращаемый список называется итоговым набором (queryset).
Содержимое итогового набора перебирается точно так же, как и содержимое списка. Например, просмотр идентификаторов, назначенных каждому объекту темы, выполняется так:
>>>topics = Topic.objects.all()
>>>for topic in topics:
... print(topic.id, topic)
...
1 Chess
2 Rock Climbing
Итоговый набор сохраняется в topics, после чего выводится атрибут id каждого объекта topic и его строковое представление. Мы видим, что теме Chess присвоен идентификатор 1, а Rock Climbing присвоен идентификатор 2.
Зная идентификатор конкретного объекта, можно получить этот объект и проанализировать содержащиеся в нем атрибуты. Просмотрим значения text и date_added для темы Chess:
>>>t = Topic.objects.get(id=1)
>>>t.text
'Chess'
>>>t.date_added
datetime.datetime(2015, 5, 28, 4, 39, 11, 989446, tzinfo=
Также можно просмотреть записи, относящиеся к конкретной теме. Ранее мы определили атрибут topic для модели Entry. Он был экземпляром ForeighKey, представляющим связь между записью и темой. Django может использовать эту связь для получения всех записей, относящихся к некоторой теме:
(1) >>>t.entry_set.all()
[ the opening phase of the game, it's important t...>] Чтобы получить данные через отношение внешнего ключа, используйте имя связанной модели, записанное в нижнем регистре, за которым следует символ подчеркивания и слово set (1) . Допустим, у вас имеются модели Pizza и Topping, и модель Topping связана с Pizza через внешний ключ. Если ваш объект называется my_pizza, для получения всех связанных с ним экземпляров Topping используется выражение my_pizza.topping_set.all(). Мы будем использовать такой синтаксис при переходе к программированию страниц, которые могут запрашиваться пользователями. Оболочка очень удобна тогда, когда вы хотите проверить, что ваш код получает нужные данные. Если в оболочке код работает так, как задумано, можно ожидать, что он будет правильно работать и в файлах, которые вы создаете в своем проекте. Если код выдает ошибки или не загружает те данные, которые должен загружать, вам будет намного проще отладить его в простой оболочке, чем при работе с файлами, генерирующими веб-страницы. В книге мы не будем часто возвращаться к оболочке, но вам не стоит забывать о ней — это полезный инструмент, который поможет вам освоить синтаксис Django для работы с данными проекта. Примечание При каждом изменении модели необходимо перезапустить оболочку, чтобы увидеть результаты этих изменений. Чтобы завершить сеанс работы с оболочкой, нажмите Сtrl+D; в Windows нажмите Ctrl+Z, а затем Enter. Упражнения 18-2. Короткие записи: метод __str__() в модели Entry в настоящее время присоединяет многоточие к каждому экземпляру Entry, отображаемому Django на административном сайте или в оболочке. Добавьте в метод __str__() команду if, добавляющую многоточие только для записей, длина которых превышает 50 символов. Воспользуйтесь административным сайтом, чтобы ввести запись с длиной менее 50 символов, и убедитесь в том, что при ее просмотре многоточие не отображается. 18-3. Django API: при написании кода для работы с данными проекта вы создаете запрос. Просмотрите документацию по созданию запросов к данным по адресу https://docs.djangoproject.com/en/1.8/topics/db/queries/. Многое из того, что вы увидите, покажется вам новым, но эта информация пригодится вам, когда вы начнете работать над собственными проектами. 18-4. Пиццерия: создайте новый проект с именем pizzeria, содержащий приложение pizzas. Определите модель Pizza с полем name, в котором хранятся названия видов пиццы (например, «Гавайская» или «Четыре сыра»). Определите модель Topping с полями pizza и name. Поле pizza должно содержать внешний ключ к модели Pizza, а поле name должно позволять хранить такие значения, как «ананас» или «грибы». Зарегистрируйте обе модели на административном сайте. Используйте сайт для ввода названий пиццы и дополнений. Изучите введенные данные в интерактивной оболочке. Обычно процесс создания веб-страниц в Django состоит из трех стадий: определения URL, написания представлений и написания шаблонов. Сначала следует определить схемы (patterns) URL. Схема URL описывает структуру URL-адреса и сообщает Django, на какие компоненты следует обращать внимание при сопоставлении запроса браузера с URL-адресом на сайте, чтобы выбрать возвращаемую страницу. Затем каждый URL-адрес связывается с конкретным представлением — функция представления читает и обрабатывает данные, необходимые странице. Функция представления часто вызывает шаблон, который строит страницу, подходящую для передачи браузеру. Чтобы вы лучше поняли, как работает этот механизм, создадим домашнюю страницу для приложения Learning Log. Мы определим URL-адрес домашней страницы, напишем для него функцию представления и создадим простой шаблон. Так как мы сейчас всего лишь убеждаемся в том, что Learning Log работает, как положено, страница пока останется простой. Когда приложение будет завершено, вы можете заниматься его оформлением, сколько душе угодно; приложение, которое хорошо выглядит, но не работает, бессмысленно. Пока на домашней странице будет отображаться только заголовок и краткое описание. Пользователь запрашивает страницы, вводя URL-адреса в браузере и щелкая на ссылках, поэтому мы должны решить, какие URL-адреса понадобятся в нашем проекте. Начнем с URL домашней страницы: это базовый адрес, используемый для обращения к проекту. На данный момент базовый URL-адрес http://localhost:8000/ возвращает сайт, сгенерированный Django по умолчанию; он сообщает о том, что проект был создан успешно. Мы изменим домашнюю страницу, связав базовый URL-адрес с домашней страницей Learning Log. В каталоге проекта learning_log откройте файл urls.py. Вы увидите в нем следующий код: urls.py (1) from django.conf.urls import include, url from django.contrib import admin (2)urlpatterns = [ (3) . .url(r'^admin/', include(admin.site.urls)), ] Первые две строки импортируют функции и модули, управляющие URL-адресами проекта и административным сайтом (1) . В теле файла определяется переменная urlpatterns (2). В файле urls.py, представляющем проект в целом, переменная urlpatterns включает наборы URL-адресов из приложений в проект. Код (3) включает модуль admin.site.urls, определяющий все URL-адреса, которые могут запрашиваться с административного сайта. Добавим в этот файл URL-адреса learning_logs: from django.conf.urls import include, url from django.contrib import admin urlpatterns = [ url(r'^admin/', include(admin.site.urls)), (1) . .url(r'', include('learning_logs.urls', namespace='learning_ logs')), ] В точке (1) добавляется строка включения модуля learning_logs.urls. Эта строка включает аргумент namespace, по которому URL-адреса learning_logs можно отличить от других URL-адресов, которые могут появиться в проекте. Данная возможность может оказаться чрезвычайно полезной по мере роста проекта. Файл urls.py по умолчанию находится в каталоге learning_log; теперь нужно создать второй файл urls.py в папке learning_logs: urls.py (1) """Определяет схемы URL для learning_logs.""" (2)from django.conf.urls import url (3)from . import views (4)urlpatterns = [ . .# Домашняя страница (5) . .url(r'^$', views.index, name='index'), ] Чтобы было понятно, с какой версией urls.py мы работаем, в начало файла добавляется строка документации (1) . Затем импортируется функция url, она необходима для связывания URL с представлениями (2). Также импортируется модуль views (3); точка приказывает Python импортировать представления из каталога, в котором находится текущий модуль urls.py. Переменная urlpatterns в этом модуле представляет собой список страниц, которые могут запрашиваться из приложения learning_logs (4). Схема URL представляет собой вызов функции url() с тремя аргументами (5). Первый аргумент содержит регулярное выражение. Django ищет в urlpatterns регулярное выражение, совпадающее со строкой запрашиваемого URL. Таким образом, регулярное выражение должно определять схему адреса, которую будет искать Django. Возьмем регулярное выражение r'^$'. Символ r сообщает Python, что последующая строка должна интерпретироваться без дополнительной обработки, а апострофы указывают, где начинается и заканчивается регулярное выражение. Символ ^ обозначает начало строки, а символ $ обозначает ее конец. В целом это выражение приказывает Python искать URL-адрес, не содержащий ничего между началом и концом URL. Python игнорирует базовый URL-адрес проекта (http://localhost:8000/), так что пустое регулярное выражение совпадает с базовым URL-адресом. Любой другой URL-адрес не будет соответствовать этому выражению, и Django вернет страницу с ошибкой, если запрашиваемый URL не соответствует ни одной из существующих схем URL. Второй аргумент url() (5) определяет вызываемую функцию представления. Когда запрашиваемый URL-адрес соответствует регулярному выражению, Django вызывает views.index (мы напишем эту функцию представления в следующем разделе). Третий аргумент определяет index для этой схемы URL, чтобы на нее можно было ссылаться в других частях кода. Каждый раз, когда потребуется предоставить ссылку на домашнюю страницу, мы будем использовать это имя вместо URL. Примечание Регулярные выражения используются почти во всех языках программирования. Они чрезвычайно полезны, но, чтобы освоить их, понадобится время. Если что-то осталось непонятным, не беспокойтесь; в ходе работы над проектом мы рассмотрим много примеров. Функция представления получает информацию из запроса, подготавливает данные, необходимые для построения страницы, и возвращает данные браузеру — часто с использованием шаблона, определяющего внешний вид страницы. Файл views.py в learning_logs был сгенерирован автоматически при выполнении команды python manage.py startapp. На данный момент его содержимое выглядит так: views.py from django.shortcuts import render # Создайте здесь свои представления. Сейчас файл только импортирует функцию render(), которая генерирует ответ на основании данных, полученных от представлений. Представление домашней страницы должно быть записано в следующем виде: from django.shortcuts import render def index(request): . ."""Домашняя страница приложения Learning Log""" . .return render(request, 'learning_logs/index.html') Если URL запроса совпадает с только что определенной схемой, Django ищет в файле views.py функцию с именем index(), после чего передает этой функции представления объект запроса. В нашем случае никакая обработка данных для страницы не нужна, поэтому код функции сводится к вызову render(). Функция render() использует два аргумента — исходный объект запроса и шаблон, используемый для построения страницы. Давайте напишем этот шаблон. Шаблон задает структуру веб-страницы. Он определяет общий внешний вид, а Django заполняет его соответствующими данными при каждом запросе страницы. Шаблон может обращаться к любым данным, полученным от представления. Так как наше представление домашней страницы никаких данных не предоставляет, шаблон получается относительно простым. В каталоге learning_logs создайте новый каталог с именем templates. В каталоге templates создайте другой каталог с именем learning_logs. На первый взгляд такая структура кажется избыточной (каталог learning_logs в каталоге templates внутри каталога learning_logs), но созданная таким образом структура будет однозначно интерпретироваться Django даже в контексте большого проекта, состоящего из множества отдельных приложений. Во внутреннем каталоге learning_logs создайте новый файл с именем index.html. Включите в него следующий текст: index.html Learning LogСоздание страниц: домашняя страница Learning Log
Сопоставление URL
Написание представления
Написание шаблона
Learning Log helps you keep track of your learning, for any topic you're
learning about.
Это очень простой файл. Если вы не знакомы с синтаксисом HTML, теги
обозначают абзацы. Теготкрывает абзац, а тег
закрывает его. Наша страница содержит два абзаца: первый содержит заголовок, а второй описывает, что пользователь может сделать с помощью приложения Learning Log.Теперь при запросе базового URL-адреса проекта http://localhost:8000/ вы увидите только что построенную страницу вместо страницы по умолчанию. Django берет запрошенный URL-адрес и видит, что он совпадает со схемой r'^$'; в этом случае Django вызывает функцию views.index(), что приводит к построению страницы с использованием шаблона, содержащегося в index.html. Полученная страница показана на рис. 18.3.
Рис. 18.3. Домашняя страница Learning Log
И хотя может показаться, что для одной страницы этот процесс слишком сложен, такое разделение URL-адресов, представлений и шаблонов работает хорошо. Оно позволяет сосредоточиться на отдельных аспектах проекта, а в более крупных проектах отдельные участники могут сосредоточиться на тех областях, в которых они наиболее сильны. Например, специалист по базам данных может заняться моделями, программист — кодом представления, а веб-дизайнер — шаблонами.
Упражнения
18-5. План питания: представьте приложение для составления плана питания на неделю. Создайте новый каталог с именем meal_planner, затем создайте в этом каталоге новый проект Django. Создайте новое приложение с именем meal_plans. Постройте простую домашнюю страницу для этого проекта.
18-6. Домашняя страница Pizzeria: добавьте домашнюю страницу в проект Pizzeria, который вы начали строить в упражнении 18-4 (с. 394).