Django в обзоре
Поскольку Django разрабатывался в динамичной обстановке новостной редакции, он был спроектирован для ускорения и упрощения распространённых задач веб-разработки. Вот краткий обзор того, как создать веб-приложение с базой данных с помощью Django.
Цель этого документа — предоставить вам достаточно технических подробностей, чтобы понять, как работает Django, но это не учебник и не справочник — но у нас есть оба! Когда вы готовы начать проект, вы можете начать с учебника или погрузиться в более подробную документацию.
Проектирование модели
Хотя вы можете использовать Django без базы данных, он поставляется с объектно-реляционным маппером, в котором вы описываете структуру вашей базы данных в коде Python.
Синтаксис модели данных синтаксис модели данных предоставляет множество богатых способов представления ваших моделей — до сих пор он решает проблемы со схемой базы данных, накопленные годами. Вот быстрый пример:
from django.db import models
class Reporter(models.Model):
full_name = models.CharField(max_length=70)
def __str__(self): # __unicode__ on Python 2
return self.full_name
class Article(models.Model):
pub_date = models.DateField()
headline = models.CharField(max_length=200)
content = models.TextField()
reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)
def __str__(self): # __unicode__ on Python 2
return self.headline
Установка
Далее, запустите утилиту командной строки Django для автоматической создания таблиц базы данных:
$ python manage.py migrate
Команда migrate анализирует все доступные модели и создаёт таблицы в вашей базе данных для тех таблиц, которых ещё нет, а также опционально предоставляет более богатый контроль схемы.
Используйте бесплатный API
После этого у вас есть бесплатный и богатый Python API для доступа к вашим данным. API создаётся на лету, никакой генерации кода не требуется:
# Import the models we created from our "news" app
>>> from news.models import Reporter, Article
# No reporters are in the system yet.
>>> Reporter.objects.all()
<QuerySet []>
# Create a new Reporter.
>>> r = Reporter(full_name='John Smith')
# Save the object into the database. You have to call save() explicitly.
>>> r.save()
# Now it has an ID.
>>> r.id
1
# Now the new reporter is in the database.
>>> Reporter.objects.all()
<QuerySet [<Reporter: John Smith>]>
# Fields are represented as attributes on the Python object.
>>> r.full_name
'John Smith'
# Django provides a rich database lookup API.
>>> Reporter.objects.get(id=1)
<Reporter: John Smith>
>>> Reporter.objects.get(full_name__startswith='John')
<Reporter: John Smith>
>>> Reporter.objects.get(full_name__contains='mith')
<Reporter: John Smith>
>>> Reporter.objects.get(id=2)
Traceback (most recent call last):
...
DoesNotExist: Reporter matching query does not exist.
# Create an article.
>>> from datetime import date
>>> a = Article(pub_date=date.today(), headline='Django is cool',
... content='Yeah.', reporter=r)
>>> a.save()
# Now the article is in the database.
>>> Article.objects.all()
<QuerySet [<Article: Django is cool>]>
# Article objects get API access to related Reporter objects.
>>> r = a.reporter
>>> r.full_name
'John Smith'
# And vice versa: Reporter objects get API access to Article objects.
>>> r.article_set.all()
<QuerySet [<Article: Django is cool>]>
# The API follows relationships as far as you need, performing efficient
# JOINs for you behind the scenes.
# This finds all articles by a reporter whose name starts with "John".
>>> Article.objects.filter(reporter__full_name__startswith='John')
<QuerySet [<Article: Django is cool>]>
# Change an object by altering its attributes and calling save().
>>> r.full_name = 'Billy Goat'
>>> r.save()
# Delete an object with delete().
>>> r.delete()
Динамический интерфейс администратора: это не просто каркас — это весь дом
После определения ваших моделей Django может автоматически создать профессиональный, готовый к работе в производстве административный интерфейс — веб-сайт, который позволяет авторизованным пользователям добавлять, изменять и удалять объекты. Это так же просто, как регистрация вашей модели в административной системе:
from django.db import models
class Article(models.Model):
pub_date = models.DateField()
headline = models.CharField(max_length=200)
content = models.TextField()
reporter = models.ForeignKey(Reporter, on_delete=models.CASCADE)
from django.contrib import admin from . import models admin.site.register(models.Article)
Здесь философия заключается в том, что вашим сайтом пользуются сотрудники, клиенты или, возможно, вы сами — и вам не придётся создавать интерфейсы бэкенда только для управления контентом.
Типичным рабочим процессом при создании приложений Django является создание моделей и запуск административных сайтов как можно быстрее, чтобы ваши сотрудники (или клиенты) могли начать заполнять данные. Затем разрабатывайте способ представления данных широкой публике.
Проектирование URL-адресов
Чистая и элегантная схема URL-адресов — важная деталь качественного веб-приложения. Django поощряет красивое проектирование URL-адресов и не добавляет в них ненужных элементов, например .php или .asp.
Для проектирования URL-адресов приложения вы создаёте модуль Python, называемый URLconf. Как оглавление вашего приложения, он содержит простое отображение между шаблонами URL-адресов и функциями обратного вызова Python. URLconf также служат для отделения URL-адресов от кода Python.
Вот как может выглядеть URLconf для примера Reporter/Article:
from django.conf.urls import url
from . import views
urlpatterns = [
url(r'^articles/([0-9]{4})/$', views.year_archive),
url(r'^articles/([0-9]{4})/([0-9]{2})/$', views.month_archive),
url(r'^articles/([0-9]{4})/([0-9]{2})/([0-9]+)/$', views.article_detail),
]
Код выше отображает URL-адреса, как простые регулярные выражения, до местоположения функций обратного вызова Python («представления»). Регулярные выражения используют скобки для «захвата» значений из URL-адресов. Когда пользователь запрашивает страницу, Django последовательно проходит через каждый шаблон и останавливается на первом, который соответствует запрошенному URL-адресу. (Если ни один из них не соответствует, Django вызывает специальное представление 404.) Это очень быстро, потому что регулярные выражения компилируются при загрузке.
Как только одно из регулярных выражений совпадёт, Django импортирует и вызывает указанное представление, которое является простой функцией Python. Каждому представлению передаётся объект запроса — содержащий метаданные запроса — и значения, захваченные в регулярном выражении.
Например, если пользователь запросил URL-адрес «/articles/2005/05/39323/», Django вызовет функцию news.views.article_detail(request,
'2005', '05', '39323').
Написание представлений
Каждое представление отвечает за выполнение одной из двух задач: возвращение объекта HttpResponse, содержащего содержимое запрашиваемой страницы, или вызов исключения, такого как Http404. Остальное — на ваше усмотрение.
Как правило, представление извлекает данные по параметрам, загружает шаблон и отображает шаблон с извлечёнными данными. Вот пример представления для year_archive из примера выше:
from django.shortcuts import render
from .models import Article
def year_archive(request, year):
a_list = Article.objects.filter(pub_date__year=year)
context = {'year': year, 'article_list': a_list}
return render(request, 'news/year_archive.html', context)
Этот пример использует систему шаблонов Django систему шаблонов, которая обладает несколькими мощными функциями, но стремится оставаться достаточно простой для использования непрограммистами.
Проектирование шаблонов
Вышеприведённый код загружает шаблон news/year_archive.html.
Django имеет путь поиска шаблонов, который позволяет минимизировать избыточность среди шаблонов. В настройках Django вы указываете список каталогов для проверки шаблонов с помощью DIRS. Если шаблон не существует в первом каталоге, он проверяет второй и так далее.
Допустим, шаблон news/year_archive.html был найден. Вот как это может выглядеть:
{% extends "base.html" %}
{% block title %}Articles for {{ year }}{% endblock %}
{% block content %}
<h1>Articles for {{ year }}</h1>
{% for article in article_list %}
<p>{{ article.headline }}</p>
<p>By {{ article.reporter.full_name }}</p>
<p>Published {{ article.pub_date|date:"F j, Y" }}</p>
{% endfor %}
{% endblock %}
Переменные заключены в двойные фигурные скобки. {{ article.headline }} означает «Вывести значение атрибута заголовка статьи».
Но точки используются не только для поиска атрибутов. Они также могут выполнять поиск ключей словаря, поиск индекса и вызов функций.
Обратите внимание, что {{ article.pub_date|date:"F j, Y" }} использует «трубу» в стиле Unix (символ «|»). Это называется фильтром шаблона, и это способ фильтрации значения переменной. В данном случае фильтр даты форматирует объект Python datetime в заданном формате (как и функция date в PHP).
Вы можете объединять любое количество фильтров. Вы можете написать собственные фильтры шаблонов. Вы можете написать собственные теги шаблонов, которые выполняют пользовательский код Python за кулисами.
Наконец, Django использует понятие «наследование шаблонов». Именно это делает {% extends "base.html" %}. Это означает «Сначала загрузите шаблон с именем «base», который определяет набор блоков, и заполните блоки следующими блоками». Короче говоря, это позволяет значительно сократить избыточность в шаблонах: каждый шаблон должен определять только то, что уникально для этого шаблона.
Вот как может выглядеть шаблон «base.html», включая использование статических файлов:
{% load static %}
<html>
<head>
<title>{% block title %}{% endblock %}</title>
</head>
<body>
<img src="{% static "images/sitelogo.png" %}" alt="Logo" />
{% block content %}{% endblock %}
</body>
</html>
Проще говоря, он определяет внешний вид сайта (с логотипом сайта) и предоставляет «дыры», которые потом заполняются дочерними шаблонами. Это упрощает переработку сайта до изменения одного файла — базового шаблона.
Это также позволяет создавать несколько версий сайта с разными базовыми шаблонами, повторно используя дочерние шаблоны. Создатели Django использовали эту технику для создания поразительно разных мобильных версий сайтов — просто создав новый базовый шаблон.
Обратите внимание, что вы не обязаны использовать систему шаблонов Django, если предпочитаете другую систему. Хотя система шаблонов Django особенно хорошо интегрирована со слоем модели Django, ничего не заставляет вас её использовать. В таком же духе, вы не обязаны использовать API базы данных Django. Вы можете использовать другой уровень абстракции базы данных, читать XML-файлы, читать файлы с диска или что угодно. Каждый компонент Django — модели, представления, шаблоны — изолирован от следующего.
Это только верхушка айсберга
Это был лишь краткий обзор функциональности Django. Вот ещё несколько полезных функций:
- Система кэширования, которая интегрируется с memcached или другими бэкендами.
- Система синдикации, которая упрощает создание RSS- и Atom-лент, как написание небольшого класса Python.
- Более привлекательные автоматически сгенерированные административные функции — этот обзор лишь слегка задел поверхность.
Следующие очевидные шаги — скачать Django, прочитать учебник и присоединиться к сообществу. Спасибо за интерес!
© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.10/intro/overview/