Представления-классы(Class-Based Views)
Представления-классы Django — это базовые абстрактные классы,
реализующие общие задачи веб-разработки на Django.
Они достаточно «мощные» в плане использования и
полностью используют возможности объектно-оринтированного
программирования и множественного наследования Python
для расширения своей функциональности.
Они больше, чем просто общие базовые упрощения использования Django —
они предоставляют утилиты, которые можно смешивать со сложными
представлениями в своих задачах.
Auth mixins
- AccessMixin
- LoginRequiredMixin
- PermissionRequiredMixin
- UserPassesTestMixin
Auth views
- LoginView
- LogoutView
- PasswordChangeDoneView
- PasswordChangeView
- PasswordContextMixin
- PasswordResetCompleteView
- PasswordResetConfirmView
- PasswordResetDoneView
- PasswordResetView
- SuccessURLAllowedHostsMixin
generic
GenericViewError
Generic base
- ContextMixin
- RedirectView
- TemplateResponseMixin
- TemplateView
- View
Generic dates
- ArchiveIndexView
- BaseArchiveIndexView
- BaseDateDetailView
- BaseDateListView
- BaseDayArchiveView
- BaseMonthArchiveView
- BaseTodayArchiveView
- BaseWeekArchiveView
- BaseYearArchiveView
- DateDetailView
- DateMixin
- DayArchiveView
- DayMixin
- MonthArchiveView
- MonthMixin
- TodayArchiveView
- WeekArchiveView
- WeekMixin
- YearArchiveView
- YearMixin
Generic detail
- BaseDetailView
- DetailView
- SingleObjectMixin
- SingleObjectTemplateResponseMixin
Generic edit
- BaseCreateView
- BaseDeleteView
- BaseFormView
- BaseUpdateView
- CreateView
- DeleteView
- DeletionMixin
- FormMixin
- FormView
- ModelFormMixin
- ProcessFormView
- UpdateView
Generic list
- BaseListView
- ListView
- MultipleObjectMixin
- MultipleObjectTemplateResponseMixin
Создадим свое первое представление¶
Давайте создадим свое первое представление. Откроем файл и добавим следующий код:
polls/views.py
from django.http import HttpResponse
def index(request):
return HttpResponse("Hello, world. You're at the polls index.")
Это самое простое представление, которое можно создать на Django. Чтобы вызвать представление, нам нужно назначить его на какой-то URL через конфигурацию URL-ов
Чтобы добавить настройки URL-ов в приложение для голосования, создадим файл . Каталог приложения должен выглядеть следующим образом:
polls/
__init__.py
admin.py
apps.py
migrations/
__init__.py
models.py
tests.py
urls.py
views.py
В файл добавим следующий код:
polls/urls.py
from django.conf.urls import url
from . import views
urlpatterns =
url(r'^$', views.index, name='index'),
Следующий шаг – добавить ссылку на в главной конфигурации URL-ов. В«mysite/urls.py« добавим импорт , затем добавим в список . Вы должны получить следующий код:
mysite/urls.py
from django.conf.urls import include, url
from django.contrib import admin
urlpatterns =
url(r'^polls/', include('polls.urls')),
url(r'^admin/', admin.site.urls),
Не совпадает с тем, что у вас получилось?
Если вы видите вместо , возможно вы используете версию Django, которая не соответствует этому учебнику. Вам следует читать старую версию учебника или обновить Django.
Вы добавили в настройки URL-ов. Давайте проверим, что он работает, запустив команду:
$ python manage.py runserver
Откройте в браузере http://localhost:8000/polls/, вы должны увидеть текст “Hello, world. You’re at the polls index.”, который вы указали в представлении .
Функция принимает четыре аргумента, два обязательных: и , и два необязательных: и . Давайте изучим эти аргументы.
argument: regex
Термин “regex” обычно используется как короткий вариант “regular expression”(регулярное выражение), который являет шаблоном для распознавания строк, или в нашем случае URL-ов. Django начинает с первого регулярного выражение и идет дальше по списку, сравнивая запрошенный URL с каждым регулярным выражением пока не будет найдено совпадение.
Обратите внимание, регулярные выражения не проверяют GET и POST аргументы, или доменное имя. Например, при запросе на , будет проверяться
При запросе на , так же будет проверяться .
Если вам нужна помощь с регулярными выражениями, почитайте статью в Википедии и документацию модуля . Также книга O’Reilly “Mastering Regular Expressions”, написанная Jeffrey Friedl, просто фантастична. На практике, однако, вам не нужно быть экспертом в регулярных выражениях, т.к. в основном вам нужно знать как составлять простые регулярные выражения. На практике сложные регулярные выражения могу влиять на производительность, по этому не следует полагаться на их широкие возможности.
Замечание о производительности: эти регулярные выражения компилируются при первом импорте модуля с конфигурацией URL-ов. Они работают очень быстро (до тех пор, пока они достаточно просты, как уже замечалось выше).
argument: view
когда Django находит подходящее регулярное выражение, Django вызывает указанную функцию представления, передавая первым аргументом объект и все распознанные регулярным выражением значения как остальные аргументы. Если регулярное выражение использует простое распознание значений, они передаются как позиционные аргументы, если используются именованное распознание, значения передаются как именованные аргументы. Позже мы рассмотрим несколько примеров.
argument: kwargs
В представление можно передать предопределенные именованные аргументы. Мы не будет использовать эту возможность в учебнике.
argument: name
Добавив имя вашему URL-у, вы можете обратиться к нему по имени из любой точки проекта, особенно шаблонов. Такой подход позволяет делать глобальные изменения в настройках URL-ов, меняя минимум файлов.
Изучив основы о запросах и ответах, приступим ко второй части учебника, чтобы начать работать с базой данных.
В этом модуле
- Django introduction
- Setting up a Django development environment
- Django Tutorial: The Local Library website
- Django Tutorial Part 2: Creating a skeleton website
- Django Tutorial Part 3: Using models
- Django Tutorial Part 4: Django admin site
- Django Tutorial Part 5: Creating our home page
- Django Tutorial Part 6: Generic list and detail views
- Django Tutorial Part 7: Sessions framework
- Django Tutorial Part 8: User authentication and permissions
- Django Tutorial Part 9: Working with forms
- Django Tutorial Part 10: Testing a Django web application
- Django Tutorial Part 11: Deploying Django to production
- Django web application security
- DIY Django mini blog
Обновление объектов из базы данных¶
Если вы удаляете поле из экземпляра модели, при повторном доступе к нему значение из базы данных снова загружается:
>>> obj = MyModel.objects.first() >>> del obj.field >>> obj.field # Loads the field from the database
- (using=None, fields=None)
Если вам нужно перезагрузить значения модели из базы данных, вы можете использовать метод . Когда этот метод вызывается без аргументов, выполняется следующее:
- Все неотложенные поля модели обновляются до значений, присутствующих в настоящее время в базе данных.
- Все кэшированные отношения очищаются перезагрузкой экземпляра.
Только поля модели загружаются из базы данных. Другие зависящие от базы данных значения, такие как аннотации, не перезагружаются. Любые атрибуты также не очищаются.
Перезагрузка происходит из базы данных, из которой был загружен экземпляр, или из базы данных по умолчанию, если экземпляр не был загружен из базы данных. Аргумент может использоваться для принудительной перезагрузки базы данных.
Можно принудительно загрузить набор полей, используя аргумент .
Например, чтобы проверить, что вызов привел к ожидаемому обновлению, вы можете написать тест, подобный следующему:
def test_update_result(self):
obj = MyModel.objects.create(val=1)
MyModel.objects.filter(pk=obj.pk).update(val=F('val') + 1)
# At this point obj.val is still 1, but the value in the database
# was updated to 2. The object's updated value needs to be reloaded
# from the database.
obj.refresh_from_db()
self.assertEqual(obj.val, 2)
Обратите внимание, что при доступе к отложенным полям загрузка значения отложенного поля происходит с помощью этого метода. Таким образом, можно настроить способ отложенной загрузки
В приведенном ниже примере показано, как можно перезагрузить все поля экземпляра при перезагрузке отложенного поля:
class ExampleModel(models.Model):
def refresh_from_db(self, using=None, fields=None, **kwargs):
# fields contains the name of the deferred field to be
# loaded.
if fields is not None
fields = set(fields)
deferred_fields = self.get_deferred_fields()
# If any deferred field is going to be loaded
if fields.intersection(deferred_fields):
# then load all of them
fields = fields.union(deferred_fields)
super().refresh_from_db(using, fields, **kwargs)
- ()
Документация Django библиотек
Рецепты Django ORM
Рецепты Django ORM — это книга о работе с моделями Django ORM и Django. Django ORM является одним из ключевых столпов Django. Он предоставляет абстракции …
Django Rest Framework
Django Rest Framework (DRF) — это библиотека, которая работает со стандартными моделями Django для создания гибкого и мощного API для проекта.
Django CMS
Django CMS — это современная платформа для веб-публикаций, построенная на Django, фреймворке веб-приложений «для перфекционистов с соблюдением сроков». Django CMS предлагает готовую поддержку общих функций, …
Channels
Channels — это проект, который использует Django и расширяет его возможности за пределы HTTP — для обработки WebSockets, протоколов чата, IoT-протоколов и многого другого. Он …
ASGI — спецификация и утилиты
ASGI (Asynchronous Server Gateway Interface) является духовным наследником WSGI, предназначенным для обеспечения стандартного интерфейса между асинхронными веб-серверами, платформами и приложениями Python. WSGI предоставил стандарт для …
Python Social Auth
Python Social Auth — это простой в настройке механизм социальной аутентификации/регистрации с поддержкой нескольких платформ и провайдеров аутентификации. Созданный с использованием базового кода из django-social-auth, …
Создание моделей¶
Теперь, после создания окружения (проекта), мы можем приступить к работе.
Каждое приложение Django состоит из пакета Python, который следует некоторым соглашениям. Django содержит команду, которая создает структуру для нового приложения, что позволяет вам сосредоточиться на написании кода, а не на создании каталогов.
Проекты или приложения
Какая разница между приложением и проектом? Приложение – это Web-приложение, которое предоставляет определенный функционал – например, Web-блог, хранилище каких-то записей или простое приложение для голосования. Проект – это совокупность приложений и конфигурации сайта. Проект может содержать несколько приложений. Приложение может использоваться несколькими проектами.
Ваше приложение может находиться где угодно в . В этом учебнике, мы будем создавать приложение голосования возле файла manage.py, и оно может быть импортировано как независимый модуль, а не подмодуль mysite.
Создавая приложение, убедитесь, что вы находитесь в том же каталоге, что и файл manage.py, и выполните команду:
$ python manage.py startapp polls
Эта команда создаст каталог polls:
polls/
__init__.py
admin.py
migrations/
__init__.py
models.py
tests.py
views.py
Эти файлы являются частью приложения голосования.
Первый шаг в создании Web-приложения с БД в Django – это создание его моделей, которые являются, по сути, схемой базы данных с дополнительными метаданными.
Философия
Модель — это основной источник данных. Он содержит набор полей и поведение данных, которые вы храните. Django следует . Смысл в том, чтобы определять модели в одном месте.
Частью работы с данными также являются миграции. В отличии от Ruby On Rails, например, миграции вынесены из файла моделей и являются просто историей, которую Django может использовать для изменения базы данных в соответствии с текущей структурой моделей.
В нашем простом приложении голосования, мы создадим две модели: Question и Choice. Question содержит вопрос и дату публикации. Choice содержит: текст ответа и количество голосов. Каждый объект Choice связан с объектом Question.
Эти понятия отображаются простыми классами Python. Отредактируйте файл polls/models.py, чтобы он выглядел таким образом:
polls/models.py
from django.db import models
class Question(models.Model):
question_text = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
class Choice(models.Model):
question = models.ForeignKey(Question)
choice_text = models.CharField(max_length=200)
votes = models.IntegerField(default=)
Код очень простой. Каждая модель представлена классом, унаследованным от . Каждая модель содержит несколько атрибутов, каждый из которых отображает поле в таблице базы данных.
Каждое поле представлено экземпляром класса – например, для текстовых полей и для полей даты и времени. Это указывает Django какие типы данных хранят эти поля.
Названия каждого экземпляра (например, question_text или pub_date ) это название поля, в “машинном”(machine-friendly) формате. Вы будете использовать эти названия в коде, а база данных будет использовать их как названия колонок.
Вы можете использовать первый необязательный аргумент конструктора класса , чтобы определить отображаемое, удобное для восприятия, название поля. Оно используется в некоторых компонентах Django, и полезно для документирования. Если это название не указано, Django будет использовать “машинное” название. В этом примере, мы указали отображаемое название только для поля Question.pub_date. Для всех других полей будет использоваться “машинное” название.
Некоторые классы, унаследованные от , имеют обязательные аргументы. Например, требует, чтобы вы передали ему . Это используется не только в схеме базы данных, но и при валидации, как мы скоро увидим.
может принимать различные необязательные аргументы; в нашем примере мы указали значение для votes` равное 0.
Блог на Django
Если вы новичок в Django, то данный проект для вас особенно хорош. Используя Django, можно полностью с нуля создать сайт-блог.
Блог — это сайт, на котором вы можете публиковать статьи, а также обновлять, редактировать или удалять их. Там будет домашняя страница с названиями всех статей, а для открытия какой-нибудь из них нужно будет кликнуть мышью по названию.
Вы сейчас как раз находитесь на аналогичном сайте и можете создать такой же блог, используя Django. Для этого вам надо знать основы Python и иметь базовые знания по технологиям фронтенда, HTML и CSS.
Преимущество Django состоит в том, что вам не придется создавать админ-панель для вашего сайта. Для этого у Django есть встроенные функции и вы легко сможете их использовать.
Подробнее с данным проектом вы можете ознакомиться в статье «How to Create a Blog Using the Django Framework».
Изменяем настройки
Давай внесём изменения в . Открой файл в текстовом редакторе, который ты выбрала ранее.
Примечание: помни, что — самый обычный файл. Ты можешь открыть его из своего редактора кода, используя меню «Файл -> Открыть». При этом ты увидишь обычное окно, в котором ты можешь перейти к своему файлу и выбрать его. Либо ты можешь открыть этот файл, перейдя в директорию проекта djangogirls на твоём рабочем столе и щёлкнув по нему правой кнопкой мыши; затем выбери свой редактор кода из предложенного списка
Важно выбрать именно редактор, поскольку у тебя могут быть установлены программы, которые откроют наш файл, но не позволят его изменить
Было бы неплохо установить корректный часовой пояс на нашем сайте. Перейди к списку часовых поясов википедии и скопируй название своего часового пояса (TZ) (например, ).
В файле settings.py найди строку, содержащую , и измени её в соответствии со своим часовым поясом:
mysite/settings.py
Код языка состоит из сокращённого названия языка, например для английского или для русского, и кода страны, например, для России или для Швейцарии. Тебе понадобится эта настройка, если ты хочешь, чтобы все встроенные кнопки и уведомления от Django были на твоём языке. Таким образом, надпись на кнопке «Cancel» будет переведена на заданный тобой язык. .
Измени язык, отредактировав следующую строку:
mysite/settings.py
Нам также необходимо добавить в настройки информацию о расположении статических файлов (мы познакомимся со статическими файлами и CSS в следующих главах). Спустись в конец файла и после переменной добавь новую — :
mysite/settings.py
Когда наcтройка имеет значение , а настройка пуста, имя хост твоего веб-сайта сверяется со списком .
Ни одно из значений не будет соответствовать имени хоста на PythonAnywhere при публикации нашего приложения, поэтому нам необходимо изменить следующую настройку:
mysite/settings.py
Проверка объектов¶
Существует три этапа проверки модели:
- Проверка полей модели —
- Проверка модели полностью —
- Проверка уникальности полей —
Все три шага выполняются при вызове метода модели .
Когда вы используете , вызов выполнит эти шаги проверки для всех полей, включенных в форму. Смотрите документацию ModelForm для получения дополнительной информации. Вам нужно только вызывать метод модели , если вы планируете самостоятельно обрабатывать ошибки проверки или если вы исключили поля из , для которых требуется проверка.
- (exclude=None, validate_unique=True)
Этот метод вызывает , и (если равно ), в этом порядке и вызывает , который имеет атрибут , содержащий ошибки всех трех этапов.
Необязательный аргумент может использоваться для предоставления списка имен полей, которые можно исключить из проверки и очистки. использует этот аргумент, чтобы исключить проверку полей, которые отсутствуют в вашей форме, поскольку любые возникшие ошибки не могут быть исправлены пользователем.
Обратите внимание, что не будет автоматически вызываться при вызове метода модели. Вам нужно будет вызвать его вручную, если вы хотите запустить одноэтапную проверку моделей для ваших собственных моделей, созданных вручную
Например:
from django.core.exceptions import ValidationError
try
article.full_clean()
except ValidationError as e
# Do something based on the errors contained in e.message_dict.
# Display them to a user, or handle them programmatically.
pass
Первый шаг, который выполняет , — это очистка каждого отдельного поля.
- (exclude=None)
Этот метод проверит все поля в вашей модели. Необязательный аргумент позволяет вам предоставить список имен полей, которые нужно исключить из проверки. Он вызовет , если какие-либо поля не пройдут проверку.
Второй шаг, который выполняет , заключается в вызове . Этот метод должен быть переопределен для выполнения пользовательской проверки вашей модели.
- ()
Этот метод должен использоваться для обеспечения пользовательской проверки модели и для изменения атрибутов вашей модели, если это необходимо. Например, вы можете использовать его для автоматического предоставления значения для поля или для проверки, которая требует доступа к более чем одному полю:
import datetime
from django.core.exceptions import ValidationError
from django.db import models
from django.utils.translation import gettext_lazy as _
class Article(models.Model):
...
def clean(self):
# Don't allow draft entries to have a pub_date.
if self.status == 'draft' and self.pub_date is not None
raise ValidationError(_('Draft entries may not have a publication date.'))
# Set the pub_date for published items if it hasn't been set already.
if self.status == 'published' and self.pub_date is None
self.pub_date = datetime.date.today()
Однако обратите внимание, что как , метод модели не вызывается, когда вы вызываете метод вашей модели. В приведенном выше примере исключение , вызванное , было создано со строкой, поэтому оно будет сохранено в специальном ключе словаря ошибок
Этот ключ используется для ошибок, которые связаны со всей моделью, а не с конкретным полем:
В приведенном выше примере исключение , вызванное , было создано со строкой, поэтому оно будет сохранено в специальном ключе словаря ошибок . Этот ключ используется для ошибок, которые связаны со всей моделью, а не с конкретным полем:
from django.core.exceptions import NON_FIELD_ERRORS, ValidationError
try
article.full_clean()
except ValidationError as e
non_field_errors = e.message_dictNON_FIELD_ERRORS
Чтобы назначить исключения конкретному полю, создайте экземпляр со словарем, где ключами являются имена полей. Мы могли бы обновить предыдущий пример, чтобы присвоить ошибку полю :
class Article(models.Model):
...
def clean(self):
# Don't allow draft entries to have a pub_date.
if self.status == 'draft' and self.pub_date is not None
raise ValidationError({'pub_date' _('Draft entries may not have a publication date.')})
...
Если вы обнаружите ошибки в нескольких полях во время , вы также можете передать имена полей отображения словаря в ошибки:
raise ValidationError({
'title' ValidationError(_('Missing title.'), code='required'),
'pub_date' ValidationError(_('Invalid date.'), code='invalid'),
})
Наконец, проверит любые уникальные ограничения на вашей модели.
- (exclude=None)
Этот метод похож на , но проверяет все ограничения уникальности вашей модели вместо отдельных значений полей. Необязательный аргумент позволяет вам предоставить список имен полей, исключаемых из проверки. Он вызовет , если какие-либо поля не пройдут проверку.
Дополнительные файлы Django-приложения
Перед размещением кода на Heroku, нам понадобится сделать четыре изменения в нашем проекте Pages:
- обновить ;
- создать новый файл ;
- установить на нашем веб-сервере ;
- изменить строчку в файле .
Внутри уже существующего файла уточним используемую версию Python — в нашем случае 3.8. Для этого добавим в нижней части файла следующие две строчки.
Pipfile
Python
python_version = «3.8»
|
1 2 |
requires python_version=»3.8″ |
Далее запускаем для генерации подходящего .
Shell
(pages) $ pipenv lock
| 1 | (pages)$pipenv lock |
В действительности, в поисках информации о виртуальном окружении, Heroku заглядывает внутрь нашего Pipfile.lock. По этой причине здесь нам пришлось добавить настройку версии языка программирования.
Затем создаем , который является специфическим файлом конфигурации для Heroku.
Shell
(pages) $ touch Procfile
| 1 | (pages)$touchProcfile |
Откройте при помощи текстового редактора и добавьте следующее:
Python
web: gunicorn pages_project.wsgi —log-file —
| 1 | webgunicorn pages_project.wsgi—log-file- |
Это говорит о том, что нам надо использовать Gunicorn, что является сервером, подходящем для продакшена, в то время как собственный сервер Django работает только в локальном окружении. Устанавливаем gunicorn при помощи Pipenv.
Shell
(pages) $ pipenv install gunicorn==19.9.0
| 1 | (pages)$pipenv install gunicorn==19.9.0 |
Конфигурация для веб-сервера находится в файле wsgi.py, который Django автоматически создает для каждого нового проекта. Он находится в основной папке нашего проекта. Поскольку наш проект называется , сам файл находится в .
Последний шаг — небольшое изменение в файле . Прокрутите вниз до части и добавьте . Результат должен получиться следующим:
Python
# pages_project/settings.py
ALLOWED_HOSTS =
|
1 2 |
# pages_project/settings.py ALLOWED_HOSTS=’*’ |
Однако мы использовали знак звездочки , а это значит, что все домены являются приемлемыми. На сайте продакшн-уровня вместо этого вам пришлось бы составить ясный список допустимых доменов.
Для проверки изменений мы выполним команду , добавляем новые файлы и затем коммитим их:
Shell
(pages) $ git status
(pages) $ git add -A
(pages) $ git commit -m «New updates for Heroku deployment»
|
1 2 3 |
(pages)$git status (pages)$git add-A (pages)$git commit-m»New updates for Heroku deployment» |
Теперь мы можем разместить код на GitHub, создав онлайн копию наших изменений в коде.
Shell
(pages) $ git push -u origin master
| 1 | (pages)$git push-uorigin master |
Краткое описание проекта
Страницы, которые должны отображаться, их URL-адреса и другие требования, перечислены ниже:
| Page | URL | Requirements |
|---|---|---|
| Home page | and | Страница индекса, описывающая сайт. |
| List of all blog posts |
Список всех сообщений блога:
|
|
| Blog author (blogger) detail page |
Информация для указанного автора (по id) и список постов:
|
|
| Blog post detail page |
Сведения о блоге.
|
|
| List of all bloggers |
Список блогеров в системе:
|
|
| Comment form page |
Создать комментарий для публикации в блоге:
|
|
| User authentication pages |
Стандартные страницы аутентификации Django для входа, выхода и установки пароля: Вход / выход должен быть доступен через ссылки боковой панели. |
|
| Admin site |
Админ-сайт должен быть включён, чтобы разрешить создание / редактирование / удаление сообщений в блогах, авторов блога и комментариев блога (это механизм для создания блогеров в блогах):
|
Кроме того, вы должны написать некоторые базовые тесты для проверки:
- Все поля модели имеют правильную метку и длину.
- Все модели имеют ожидаемое имя объекта (например,выдаёт ожидаемое значение).
- Модели имеют ожидаемый URL для отдельных записей в блогах и комментариях (например, возвращает ожидаемый URL-адрес).
- Страница BlogListView (страница на всех блогах) доступна в ожидаемом месте (например, /blog/blogs)
- Страница BlogListView (страница на всех блогах) доступна на ожидаемом именованном URL-адресе (например, ‘blogs’)
- Страница BlogListView (страница на всех блогах) использует ожидаемый шаблон (например, по умолчанию)
- BlogListView разбивает записи на 5 (по крайней мере, на первой странице)
Примечание: Конечно, есть много других тестов, которые вы можете запустить. Используйте на своё усмотрение, но мы ожидаем, что вы сделаете хотя бы тесты выше.
В следующем разделе показаны сайта, который выполняет перечисленные выше требования.
Configuring the database
Now, when the project stub is ready, let’s do some fine tuning. Open for editing settings.py. To do it, select the file in the Project tool window, and press F4. The file opens in its own tab in the editor.
Specify which database you are going to use in your application. For this purpose, find the variable: click Ctrl+F, and in the search field start typing the string you are looking for. Then, in the line, add the name of your database management system after dot (you can use any one specified after comment, but for the beginning we’ll start with sqlite3.)
In the line, enter the name of the desired database, even though it doesn’t yet exist.
Обзор
Эта статья показывает, как можно создать «скелет»(прототип) сайта, который затем можно расширить при помощи различных настроек, url адресов, моделей, представлений, и шаблонов (эти темы будут объясняться в последующих статьях).
Алгоритм следующий:
- Использовать для создания папки проекта, шаблонов остальных файлов, и скрипта для управления проектом (manage.py).
-
Использовать manage.py для создания одного или нескольких приложений.
Примечание: Сайт может состоять из одной или нескольких различных частей, например: основная часть, блог, вики, раздел загрузок, и так далее. Философия Django подталкивает разработчиков создавать эти части, как разные приложения, которые, если понадобится, могут быть использованы повторно в других проектах.
- Зарегистрировать в настройках эти приложения, чтобы использовать их в проекте.
- Настроить маршруты url адресов для каждого из приложений.
Для Сайта местной библиотеки папка сайта и проекта будет называться locallibrary, и у нас будет одно приложение с названием catalog. Верхняя структура проекта будет следующей:
Следующие разделы статьи разложат по полочкам этапы создания «скелета», и покажут вам, как можно проверить сделанные изменения. В конце статьи мы обсудим некоторые другие настройки сайта, которые можно назначить на этом этапе.
Расширяем возможности шаблона в Django
Главная сила шаблонов в их способности расширяться. Если задуматься, то на большинстве сайтов есть содержимое, которое повторяется на каждой странице (заголовки, футеры и так далее). Для разработчиков было бы здорово иметь одно установленное место для кода заголовка, которое бы передавалось по наследству каждому шаблону.
Это возможно! Создадим HTML-файл , у которого будет заголовок с ссылками на две созданные нами страницы. Название для файла можно выбрать любое, в данной случае просто стало традицией. Теперь закрываем веб-сервер и затем создаем новый файл.
Shell
(pages) $ touch templates/base.html
| 1 | (pages)$touchtemplatesbase.html |
В Django, шаблонный язык для добавления ссылок и базовых логических операций минимален. Ознакомиться со встроенным списком шаблонных тегов можно в . Шаблонные теги оформляются так , где «something» сам по себе является тегом. Вы даже можете создать собственные шаблонные теги.
Для добавления URL-ссылок в проект мы можем использовать , который присваивает себе имя URL паттерна в качестве аргумента. Помните, как мы добавляли опциональные URL названия двум адресам в ? Это было сделано именно по этой причине. Тег использует эти названия для автоматического создания ссылок.
URL путь для нашей домашней страницы был назван , поэтому для настройки ссылки к ней мы будем использовать: .
Python
<!— templates/base.html —>
<header>
<a href=»{% url ‘home’ %}»>Home</a> | <a href=»{% url ‘about’ %}»>About</a>
</header>
{% block content %}
{% endblock content %}
|
1 2 3 4 5 6 7 |
<!—templatesbase.html—> <header> <ahref=»{% url ‘home’ %}»>Home<a>|<ahref=»{% url ‘about’ %}»>About<a> <header> {%block content%} {%endblock content%} |
Внизу мы добавляем тег-блок под названием . При наследовании, блоки могут быть переписаны дочерними шаблонами. Закрывающему тегу можно дать название — просто напишите . Это может стать хорошей подсказкой при ориентировке в крупных файлах шаблонов.
Python
<!— templates/home.html —>
{% extends ‘base.html’ %}
{% block content %}
<h1>Homepage</h1>
{% endblock content %}
|
1 2 3 4 5 6 |
<!—templateshome.html—> {%extends’base.html’%} {%block content%} <h1>Homepage<h1> {%endblock content%} |
и
Python
<!— templates/about.html —>
{% extends ‘base.html’ %}
{% block content %}
<h1>About page</h1>
{% endblock content %}
|
1 2 3 4 5 6 |
<!—templatesabout.html—> {%extends’base.html’%} {%block content%} <h1>Aboutpage<h1> {%endblock content%} |
Запускаем сервер с и открываем страницы и вновь. Как видите, на обоих страницах появились заголовки.
Неплохо, правда?
Домашняя страница с заголовком
Страница «About» с заголовком
С шаблонами можно осуществить множество операций. Обычно создается файл а затем в проекте добавляются дополнительные шаблоны которые расширяют базовый файл.
