Django tutorial python: Writing your first Django app, part 2 | Django documentation

Руководство по Django часть 2: создание скелета — Изучение веб-разработки

Это вторая статья из нашего руководства по Django, которая показывает, как можно создать «скелет» сайта, как фундамент, на котором можно строить всё остальное: настройки, ссылки, модели, контроллеры и представления.

Эта статья показывает, как можно создать «скелет»(прототип) сайта, который затем можно расширить при помощи различных настроек, url адресов, моделей, представлений, и шаблонов (эти темы будут объясняться в последующих статьях).

Алгоритм следующий:

1. Использовать django-admin для создания папки проекта, шаблонов остальных файлов, и скрипта для управления проектом (manage.py).
2. Использовать manage.py для создания одного или нескольких приложений.

   Примечание: Сайт может состоять из одной или нескольких различных частей, например: основная часть, блог, вики, раздел загрузок, и так далее. Философия Django подталкивает разработчиков создавать эти части, как разные приложения, которые, если понадобится, могут быть использованы повторно в других проектах. 

3. Зарегистрировать в настройках эти приложения, чтобы использовать их в проекте.
4. Настроить маршруты url адресов для каждого из приложений.

Для Сайта местной библиотеки папка сайта и проекта будет называться locallibrary, и у нас будет одно приложение с названием catalog. Верхняя структура проекта будет следующей:

locallibrary/         
    manage.py         
    locallibrary/     
    catalog/          

Следующие разделы статьи разложат по полочкам этапы создания «скелета», и покажут вам, как можно проверить сделанные изменения. В конце статьи мы обсудим некоторые другие настройки сайта, которые можно назначить на этом этапе.

Для начала откройте командную строку/терминал, перейдите в ту папку, куда вы хотите поместить проект Django(лучше в папке профиля пользователя C:\Users\user_name, при запуске командной строки используется именно эта директория), и создайте папку для вашего нового сайта (в данном случае: locallibrary). Затем войдите в эту папку, используя команду cd:

mkdir locallibrary
cd locallibrary

Создайте новую папку, используя команду django-admin startproject как в примере ниже, и затем зайдите в созданную папку.

  django-admin startproject locallibrary .
cd locallibrary

Команда django-admin создаст файловую структуру, как в примере ниже:

locallibrary/
    manage.py
    locallibrary/
        settings.py
        urls.py
        wsgi.py

Подпапка проекта locallibrary это ключевая директория нашего проекта: 

• settings.py содержит в себе все настройки проекта. Здесь мы регистрируем приложения, задаём размещение статичных файлов, настройки базы данных и так далее.  
• urls.py задаёт ассоциации url адресов с представлениями. Несмотря на то, что этот файл может содержать все настройки url, обычно его делят на части, по одной на приложение, как будет показано далее.
• wsgi.py используется для налаживания связи между вашим Django приложением и веб-сервером. Вы можете воспринимать его, как утилиту.

Скрипт manage.py используется для создания приложений, работы с базами данных и для запуска отладочного сервера. 

Выполнив предыдущие шаги, запустите следующую команду для создания приложения catalog, который будет размещён внутри папки locallibrary (команду необходимо выполнять из папки, в которой находится manage.py):

python3 manage.py startapp catalog

Примечание: приведённая выше команда справедлива для GNU Linux/Mac OS. На Windows команда должна иметь вид: py -3 manage.py startapp catalog

Если вы работаете под Windows, заменяйте команду python3 на py -3 в этой и следующих статьях.

Эта команда создаст новую папку и наполнит её файлами различных частей приложения (выделенные полужирным ниже). Большинство файлов названы, исходя из их назначения (например контроллеры(views) должны находится во views.py, модели в models.py, тесты в tests.py, настройки административной части в admin.py, регистрация приложения в apps.py) и уже содержат некоторый шаблонный код для работы с вышеназванными объектами.

Обновлённая директория должна выглядеть следующим образом:

locallibrary/
    manage.py
    locallibrary/
    catalog/
        admin.py
        apps.py
        models.py
        tests.py
        views.py
        __init__.py
        migrations/

Кроме перечисленных выше файлов были созданы:

• Папка migrations используется, чтобы хранить»миграции» — файлы, которые позволяют вам автоматически обновлять базу данных по мере изменения моделей. 
• __init__.py — пустой файл для того, чтобы Django и Python распознавали папку как Python модуль и позволяет нам использовать его объекты внутри других частей проекта.

Примечание: Заметили, что некоторых файлов не хватает? В то время, как там нашли себе место файлы для контроллеров(views) и моделей(models), файлов для настройки url соотносителя, шаблонов, и статичных файлов создано не было. Далее мы покажем, как их создать (они не обязательны для каждого сайта, но нужны в данном примере).

После создания приложения, нам нужно зарегистрировать его в проекте, чтобы различные утилиты затрагивали его своим действием (например при добавлении моделей в базу данных). Приложения регистрируются добавлением их названий в список INSTALLED_APPS в настройках проекта(который, как мы помним, называется settings.py). 

Откройте файл locallibrary/locallibrary/settings.py и найдите в нём список INSTALLED_APPS . Затем добавьте новую строку в конец списка, как показано полужирным ниже.

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'catalog.apps.CatalogConfig', 
]

Новая строка указывает на файл конфигурации приложения (CatalogConfig), который был создан в /locallibrary/catalog/apps.py , когда вы создали приложение.

Примечание: Легко заметить, что в INSTALLED_APPS уже подключено большое количество приложений (и объектов MIDDLEWARE, ниже в файле конфигурации). Они добавляют поддержку админ-панели Django и, как следствие, огромное количество функциональности (включая сессии, аутентификацию и прочее).

На этом шаге обычно указывают базу данных для будущего проекта — имеет смысл использовать для разработки и размещённого в Сети одну и ту же базу данных, по возможности, чтобы исключить различия в поведении.  Про различные варианты вы можете прочитать в документации Django в разделе Базы данных. 

Мы будем использовать базу данных SQLite для этого проекта, потому что не предполагаем большое количество одновременных запросов на неё, а ещё потому, что для её настройки совсем не надо ничего делать! Вы можете видеть, что база данных уже настроена в settings.py (подробная информация указана ниже):

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

Так как мы используем SQLite, то нам не нужно ничего делать.

Давайте продолжим!

Файл settings.py так же применяется и для некоторых других настроек, но на данном шаге имеет смысл поменять разве что TIME_ZONE — это значение должно быть представлено строкой, указанной в списке часовых поясов tz (колонка TZ в таблице, в строке временной зоны, которая вам нужна). Измените TIME_ZONE на одну из строк из таблицы, которая отвечает вашему часовому поясу. Например:

TIME_ZONE = 'Europe/Moscow'

В файле присутствует две настройки, которые не нужно менять сейчас, но о назначении которых следует знать:

• SECRET_KEY. Это секретный ключ, который используется Django для поддержки безопасности сайта. Если вы раскроете этот ключ в процессе разработки кому-либо, то необходимо будет его сменить (возможно считать его с какого-либо файла на сервере или переменной окружения) когда будете размещать проект на сервер. 
• DEBUG. Включает подробные сообщения об ошибках, вместо стандартных HTTP статусов ответов. Должно быть изменено на False на сервере, так как эта информация очень много расскажет взломщикам. 

При создании сайта, был создан файл сопоставления URL (urls.py) в корне проекта. Хотя можно использовать его для обработки всех URL адресов, более целесообразно подключать отдельные файлы сопоставлений для каждого приложения.

Откройте locallibrary/locallibrary/urls.py и обратите внимание на закомментированный текст, который объясняет суть происходящего. 

"""
locallibrary URL Configuration

The `urlpatterns` list routes URLs to views.blog/', include('blog.urls'))
"""
from django.urls import path
from django.contrib import admin


urlpatterns = [
    path('admin/', admin.site.urls),
]

URL соотношения хранятся в переменной urlpatterns, которая является списком функций path(). Каждая path() функция или ассоциирует шаблон URL с контроллером(views) или же его с другим таким списком (во втором случае, первый URL становится «базовым» для других, которые определяются в дочернем списке). Список urlpatterns инициализирует список функции, которая, например, соотносит admin/ с модулем admin.site.urls , который содержит собственный файл-соотноситель.

Добавьте строчки, приведённые ниже в низ файла urls.py , чтобы добавить новый элемент в список urlpatterns. Этот элемент содержит url() который направляет запросы с URL catalog/ к модулю  catalog.urls (файл с относительным путём /catalog/urls.py).

from django.urls import include
from django.urls import path
urlpatterns += [
     path('catalog/', include('catalog.urls')),
]

Теперь давайте перенаправим корневой URL нашего сайта (например 127.0.0.1:8000) на URL 127.0.0.1:8000/catalog/; это единственное приложение, которое мы собираемся использовать, поэтому это вполне разумно. Чтобы это использовать, нам понадобится специальная функция (RedirectView), которая принимает первым параметром новый относительный URL на который следует перенаправлять (/catalog/) когда указанный в функции url() адрес  соотносится с адресом запроса (корневой URL, в данном случае).

Добавьте следующие строчки, тоже в конец файла:

from django.views.generic import RedirectView
urlpatterns += [
    path('', RedirectView.as_view(url='/catalog/', permanent=True)),
]

Django не размещает статические файлы(CSS, JavaScript, и изображения) по умолчанию, но это было бы крайне полезно на этапе разработки нашего сайта. В самом конце нашего URL соотносителя, можно включить размещение статических файлов. 

Добавьте последнюю часть в конец файла:

# Используйте static() чтобы добавить соотношения для статических файлов
# Только на период разработки
from django.conf import settings
from django.conf.urls.static import static

urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

Примечание: Существуют различные способы дополнения списка urlpatterns (в примере мы просто добавляли объект, используя оператор += чтобы чётко разделить изначальный и дописанный код). Вместо этого, мы могли бы добавить соотношения внутрь определения переменной:

urlpatterns = [   path('admin/', admin.site.urls),
path('catalog/', include('catalog.urls')),path('',
RedirectView.as_view(url='/catalog/', permanent=True)), ] +
static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)

Кроме того, мы добавили import вниз файла (from django.urls import include) ,чтобы видеть, что мы добавили, но обычно все инструкции import добавляются в верхнюю часть файла.

Напоследок, создайте файл urls.py внутри папки catalog, и добавьте следующий код, чтобы определить (пустой) urlpatterns. Сюда мы будем добавлять наши URL соотношения, по мере разработки сайта. 

from django.urls import path
from . import views


urlpatterns = [

]

На этом, мы создали прототип сайта. Пока сайт ничего не умеет делать, но стоит запустить его, чтобы убедиться, что мы ничего не сломали. 

До этого, нам предстоит впервые запустить  миграцию базы данных. Это обновит нашу базу данных и добавит туда необходимые модели (и уберёт некоторые предупреждения, которые были бы показаны при попытке запуска).

Запуск миграций базы данных

Django использует Объектный Соотноситель Связей (ORM) чтобы соотносить определения моделей в Django приложении со структурами данных, которые используются базой данных. Когда мы меняем наши модели, Django отслеживает изменения и может создать файлы миграций (в папке /locallibrary/catalog/migrations/) чтобы применить соответствующие структуры данных к базе, чтобы та соответствовала модели.

При создании сайта, Django автоматически добавил несколько моделей, чтобы мы могли их использовать в админ-панели (о которой мы поговорим позже). Выполните следующие команды, чтобы создать нужные таблицы в базе данных, соответствующие этим моделям (убедитесь, что вы находитесь в папке с manage.py):

python3 manage.py makemigrations
python3 manage.py migrate

Предупреждение: Необходимо выполнять команды выше каждый раз, когда вы меняете модели таким образом, что структура таблицы изменится(включая добавления и удаления как отдельных полей, так и целых моделей).

Команда makemigrations создаёт (но не применяет) миграции для всех приложений, которые установлены в ваш проект (вы так же можете указать в конце имя конкретного приложения, чтобы создать миграции только для него). Это даёт вам возможность проверить код перед тем, как их применить — когда вы станете хорошо разбираться в Django, то сможете даже менять их!

Команда migrate применяет созданные миграции к базе (Django отслеживает, какие миграции были созданы для данной базы).

Примечание: Посмотрите раздел Миграции в документации Django чтобы получить информацию о менее распространённых командах для управления миграциями.

Запуск сайта

Во время разработки, вы можете проверить свой сайт, разместив его на встроенном отладочном сервере, и просмотрев его в своём браузере. 

Примечание: Отладочный веб-сервер не настолько функционален и производителен, для постоянного размещения , но это самый простой способ запустить свой сайт на Django и проверить его на наличие ошибок. По умолчанию, он разместит сайт на вашем компьютере (http://127.0.0.1:8000/), но вы так же можете указать различные компьютеры в вашей сети для этой цели. Для получения большего количества информации загляните в раздел django-admin и manage.py: отладочный сервер документации Django.

Запустите веб-сервер, используя команду runserver (в той же папке, что и manage.py):

python3 manage.py runserver

 Performing system checks...

 System check identified no issues (0 silenced).
 September 22, 2016 - 16:11:26
 Django version 1.10, using settings 'locallibrary.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CTRL-BREAK.

Когда сервер запустится, вы сможете посетить сайт по адресу http://127.0.0.1:8000/ в вашем веб-браузере. Вы должны увидеть страницу с ошибкой, навроде этой:

Не волнуйтесь! Эта страница должна появиться и сообщить нам, что мы ещё не настроили ни одной страницы в модуле catalogs.urls (на который мы были перенаправлены запросили корневой URL сайта). 

Примечание: Показанная выше страница открывает нам одно из замечательных свойств Django — автоматические отчёты об ошибках. На экране с ошибкой отображается множество полезной информации, когда страница не найдена, или ошибка была вызвана кодом. В данном случае, мы видим, что запрошенный URL  не соответствует ни одному шаблону (из указанных). Подобные отчёты будут выключены при DEBUG=False (когда мы разместим приложение в Сеть), в этом случае будет показана менее информативная, но более дружелюбная к пользователю страница(которую вам надо будет создать — прим. переводчика).

На данном этапе, мы поняли, что Django работает должным образом! 

Примечание: вам следует перезапускать миграцию и заново тестировать сайт, после того как вы делаете важные изменения. Поверьте, это не займёт много времени!

Папка catalog/ содержит файлы контроллеров(views), моделей(models), и других частей приложения. Просмотрите эти файлы. 

Как было написано выше, URL соотноситель для админ-панели был подключён в файле urls.py. Войдите в административную часть и посмотрите, что произойдёт (вы можете найти URL из соотношения выше).

Теперь вы создали полноценный скелет веб-приложения, который теперь вы можете расширить url соотносителями, контроллерами(views) и моделями(models).

Теперь скелет Сайта местной библиотеки сделан и запущен, теперь самое время начать писать код, который научит сайт делать то, что он должен делать. 

Руководство Django часть 4: административная панель Django — Изучение веб-разработки

Теперь, когда модели для сайта местной библиотеки созданы, добавим некоторые «настоящие» данные о книгах, используя административную панель Django Admin. Для начала мы покажем, как зарегистрировать в ней модели, потом как войти и создать какие-нибудь данные. В конце статьи мы покажем некоторые способы дальнейшего улучшения вида админ-панели.

Приложение Django admin может использовать ваши модели для автоматического создания части сайта, предназначенной для создания, просмотра, обновления и удаления записей. Это может сэкономить вам много времени в процессе разработки, упрощая тестирование ваших моделей на предмет правильности данных. Оно также может быть полезным для управления данными на стадии публикации, в зависимости от типа веб-сайта. Проект Django рекомендует это приложение только для управления внутренними данными (т.е.для использования администраторами, либо людьми внутри вашей организации), так как модельно-ориентированный подход не обязательно является наилучшим интерфейсом для всех пользователей и раскрывает много лишних подробностей о моделях.

Все необходимые настройки, которые необходимо включить  в admin приложение вашего веб-сайта, были сделаны автоматически, когда вы создали каркас проекта ( информацию о необходимых актуальных зависимостях смотрите здесь —  Django docs) . В результате все, что необходимо сделать для того, чтобы добавить модели в приложение admin, это зарегистрировать их. В конце этой статьи мы представим краткую демонстрацию того, каким образом  можно дополнительно настроить админ-панель для лучшего отображения данные наших моделей.

После регистрации моделей мы покажем как создать нового суперпользователя , войти на сайт от его имени и создать книги, авторов, экземпляры книг и жанры. Это будет полезным для тестирования представлений и шаблонов, которые мы начнём создавать в следующей части руководства.

Вначале откройте файл admin.py в папке приложения (/locallibrary/catalog/admin.py). Пока он выглядит так (заметьте, что он уже содержит импорт  django.contrib.admin):

from django.contrib import admin

Зарегистрируйте модели путём вставки следующего текста в нижнюю часть этого файла. Этот код просто импортирует модели и затем вызывает  admin.site.register для регистрации каждой из них.

from .models import Author, Genre, Book, BookInstance

admin.site.register(Book)
admin.site.register(Author)
admin.site.register(Genre)
admin.site.register(BookInstance)

Примечание: Если вы приняли участие в создании модели для представления естественного языка книги (см. обучающую статью о моделях), импортируйте и зарегистрируйте её тоже!

Это самый простой способ регистрации модели или моделей. Админ-панель имеет множество настроек. Мы рассмотрим другие способы регистрации ваших моделей ниже.

Для того, чтобы войти в админ-панель, нам необходимо иметь учётную запись пользователя со статусом Staff (сотрудники). Для просмотра и создания записей, пользователю также понадобится разрешение для управления всеми нашими объектами. Вы можете создать учётную запись  «superuser», которая даёт полный доступ к сайту и все необходимые разрешения, используя manage.py.

Для создания суперпользователя вызовите следующую команду из той же папки, где расположен manage.py. Вас попросят ввести имя пользователя, адрес электронной почты и надёжный пароль. 

python3 manage.py createsuperuser

После выполнения этой команды новый суперпользователь будет добавлен в базу данных. Теперь перезапустите сервер, чтобы можно было протестировать вход на сайт:

python3 manage.py runserver

Для входа в админ-панель откройте ссылку /admin (например  http://127.0.0.1:8000/admin) и введите логин и пароль вашего нового суперпользователя  (вас перенаправят на login-страницу и потом обратно на /admin после ввода всех деталей).

В этой части сайта отображаются все наши модели, сгруппированные по установленному приложению. Вы можете кликнуть на названии модели, чтобы получить список всех связанных записей, далее можете кликнуть на этих записях, для их редактирования . Также можно непосредственно кликнуть на ссылку Add, расположенную рядом с каждой моделью, чтобы начать создание записи этого типа. 

Кликните на ссылке Add справа от Books, чтобы создать новую книгу (появится диалоговое окно как на картинке внизу). Заметьте, что заголовок каждого поля — это тип используемого виджета, и    help_text (если есть) совпадает со значением, которое вы указали в модели. 

Введите значение для полей. Вы можете создавать новых авторов или жанры, нажимая на значок «+ «, расположенный рядом с соответствующим полем (или выберите существующее значение из списков, если вы уже создали их). Когда вы закончили, нажмите на SAVE,  Save and add another, или Save and continue editing, чтобы сохранить записи.

Примечание: А сейчас, хотелось бы, чтобы вы добавили несколько книг, авторов и жанров (например,  Фэнтези) в ваше приложение. Удостоверьтесь, что каждый автор и жанр включает пару различных книг (позже, когда мы реализуем представления «list» и «detail», это сделает их более интересными).

После того, когда книги добавлены, для перехода на главную страницу админ-панели кликните на ссылке Home в верхней части страницы. Потом кликните на ссылке Books для отображения текущего списка книг (или на одной из других ссылок, чтобы увидеть список соответствующей модели). После добавления нескольких книг список может выглядеть наподобие скриншота ниже.  Отображается название каждой из книг. Его возвращает метод __str__() в модели Book, созданной в предыдущей статье.

Для удаления книги из этого списка выберите чекбокс рядом с ней и действие delete…  из выпадающего списка Action, а затем нажмите кнопку Go. Также можно добавить новую книгу, нажав на кнопку ADD BOOK. 

Вы можете редактировать книгу, кликнув по ссылке с её названием. Страница редактирования книги, приведённая ниже, практически идентична странице добавления новой книги. Основные отличия — это заголовок страницы (Change book) и наличие кнопок Delete, HISTORY и VIEW ON SITE.  Последняя присутствует, так как мы определили метод get_absolute_url() в нашей модели.

Теперь перейдите назад на страницу Home (используя ссылку Home в навигационной цепочке вверху страницы) и просмотрите списки Author и Genre. В них уже должно быть несколько элементов, созданных при добавлении новых книг. Если хотите, добавьте ещё.

Однако у вас не будет ни одного экземпляра книги, потому что они не создаются из модели Book (хотя можно создать книгу из модели BookInstance — такова природа поля ForeignKey). Для отображения страницы Add book instance (см. рисунок ниже) вернитесь на страницу Home  и нажмите кнопку Add. Обратите внимание на длинный уникальный Id для идентификации конкретного экземпляра книги в библиотеке.

Создайте несколько экземпляров для каждой из ваших книг. Установите статус Available (доступен) для некоторых экземпляров и On loan (выдан) для остальных. Если статус экземпляра not Available (недоступен), то также установите дату возврата (Due back).

Вот и все! Вы изучили как запустить и использовать админ-панель. Также были созданы записи для Book, BookInstance, Genre и Author, которые можно будет использовать после создания наших собственных представлений и шаблонов.

Django выполняет неплохую работу по созданию базовой админ-панели используя информацию из зарегистрированных моделей:

• каждая модель имеет список записей, каждая из которых идентифицируется строкой, создаваемой методом __str__() модели, и связана с представлением для её редактирования. По умолчанию, в верхней части этого представления находится меню действий, которое может быть использовано для удаления нескольких записей за раз
• Формы для редактирования и добавления записей содержат все поля модели, которые расположены вертикально в порядке их объявления в модели.  

Можно настроить интерфейс пользователя для упрощения его использования. Некоторые доступные настройки:

• List views:
  • добавление дополнительных отображаемых полей или информации для каждой записи. 
  • добавление фильтров для отбора записей по разным критериям (например, статус выдачи книги).
  • добавление дополнительных вариантов выбора в меню действий и места расположения этого меню на форме.
• Detail views
  • выбор отображаемых полей, их порядка, группирования и т.д. 
  • добавление связанных полей к записи  (например, возможности добавления и редактирования записей книг при создании записи автора).

В этом разделе рассмотрим некоторые изменения для совершенствования интерфейса пользователя нашей местной библиотеки, а именно: добавление дополнительной информации в списки моделей Book и Author ,  а также улучшение расположения элементов соответствующих представлений редактирования. Пользовательский интерфейс моделей Language and Genre изменять не будем, так как это не даст заметного улучшения, поскольку он содержит только по одному полю!

Полное руководство по всем возможным вариантам настройки админ-панели можно найти в The Django Admin site (документация Django).

Регистрация класса ModelAdmin

Для изменения отображения модели в пользовательском интерфейсе админ-панели, необходимо определить класс ModelAdmin  (он описывает расположение элементов интерфейса, где Model — наименование модели) и зарегистрировать его для использования с этой моделью.

Давайте начнём с модели Author. Откройте файл admin.py в каталоге приложения (/locallibrary/catalog/admin.py). Закомментируйте исходную регистрацию (используя префикс #) этой модели:

# admin.site.register(Author)

Теперь добавьте новый класс AuthorAdmin и зарегистрируйте его как показано ниже:

class AuthorAdmin(admin.ModelAdmin):
    pass


admin.site.register(Author, AuthorAdmin)

Сейчас мы добавим классы ModelAdmin для моделей Book  BookInstance. Нам снова нужно закомментировать исходную регистрацию:

#admin.site.register(Book)
#admin.site.register(BookInstance)

В этот раз для создания и регистрации новых моделей используем декоратор  @register (он делает то же самое, что и метод admin.site.register()):

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):
    pass



@admin.register(BookInstance)
class BookInstanceAdmin(admin.ModelAdmin):
    pass

Пока что все наши admin-классы пустые (см. «pass"), поэтому ничего не изменится ! Добавим код для задания особенностей интерфейса моделей.

Настройка отображения списков

Сейчас приложение LocalLibrary отображает всех авторов, используя имя объекта, возвращаемое методом __str__() модели. Это приемлемо, когда есть только несколько авторов, но, если их количество значительно, возможны дубликаты. Чтобы различить их или просто отобразить более интересную информацию о каждом авторе, можно использовать list_display (для добавления дополнительных полей). 

Замените класс AuthorAdmin кодом, приведённым ниже. Названия полей, которые будут отображаться в списке, перечислены в кортеже list_display в требуемом порядке  (это те же имена, что и в исходной модели).

class AuthorAdmin(admin.ModelAdmin):
    list_display = ('last_name', 'first_name', 'date_of_birth', 'date_of_death')

Перезапустите сайт и перейдите к списку авторов. Указанные поля должны отображаться следующим образом:

Для нашей модели Book добавим отображение полей author и genre. Поле author  — это  внешний ключ (ForeignKey ) связи один к одному, поэтому оно будет представлено значением __str()__  для связанной записи. Замените класс BookAdmin на версию, приведённую ниже.

class BookAdmin(admin.ModelAdmin):
    list_display = ('title', 'author', 'display_genre')

К сожалению, мы не можем напрямую поместить поле genre в list_display, так как оно является  ManyToManyField (Django не позволяет это из-за большой «стоимости» доступа к базе данных). Вместо этого мы определим функцию display_genre для получения строкового представления информации (вызов этой функции есть в list_display,  её определение см. ниже).

Примечание: Получение здесь значения поля genre возможно не самая хорошая идея вследствие «стоимости» операции базы данных. Мы показываем это, потому что вызов функций в ваших моделях может быть очень полезен по другим причинам, например, для добавления ссылки  Delete рядом с каждым пунктом списка.

Добавьте следующий код в вашу модель Book (models.py). В нем создаётся строка из первых трёх значений поля genre (если они существуют) и short_description,  которое может быть использовано в админ-панели.

    def display_genre(self):
        """
        Creates a string for the Genre. This is required to display genre in Admin.
        """
        return ', '.join([ genre.name for genre in self.genre.all()[:3] ])
    display_genre.short_description = 'Genre'

После сохранения модели и обновления админ-панели, перезапустите её и перейдите на страницу списка Books. Вы должны увидеть список книг, наподобие приведённого ниже:

Модель Genre (и модель Language, если вы её определили) имеет единственное поле. Поэтому нет необходимости создания для них дополнительных моделей с целью отображения дополнительных полей.

Примечание: целесообразно, чтобы в списке модели BookInstance отображались хотя бы статус и ожидаемая дата возврата. Мы добавили это в качестве «испытания» в конце этой статьи!

Добавление фильтров списка

Если в вашем списке есть множество элементов, может быть полезной возможность фильтрации отображаемых пунктов. Это выполняется путём перечисления их в атрибуте list_filter. Замените класс BookInstanceAdmin на следующий:

class BookInstanceAdmin(admin.ModelAdmin):
    list_filter = ('status', 'due_back')

Представление списка теперь будет содержать панель фильтрации справа. Обратите внимание, как выбирать даты и статус для фильтрации:

Формирование макета с подробным представлением

По умолчанию в представлениях деталей отображаются все поля по вертикали в порядке их объявления в модели. Вы можете изменить порядок декларации, какие поля отображаются (или исключены), используются ли разделы для организации информации, отображаются ли поля горизонтально или вертикально, и даже какие виджеты редактирования используются в админ-формах.

Примечание: Модели LocalLibrary относительно просты, поэтому нам не нужно менять макет, но мы всё равно внесём некоторые изменения, просто чтобы показать вам, как это сделать.

Управление отображаемыми и вложенными полями

Обновите ваш AuthorAdmin класс, чтобы добавить строку полей, как показано ниже (выделено полужирным шрифтом):

class AuthorAdmin(admin.ModelAdmin):
    list_display = ('last_name', 'first_name', 'date_of_birth', 'date_of_death')
    fields = ['first_name', 'last_name', ('date_of_birth', 'date_of_death')]

Атрибут полей перечисляет только те поля, которые должны отображаться в форме, по порядку. Поля отображаются по вертикали по умолчанию, но будут отображаться горизонтально, если вы дополнительно группируете их в кортеже (как показано в полях «date» выше).

Перезагрузите приложение и перейдите к подробному представлению автора — он должен теперь отображаться, как показано ниже:

Примечание: Так же, вы можете использовать exclude атрибут для объявления списка атрибутов, которые будут исключены из формы (все остальные атрибуты в модели, будут отображаться). 

Разделение на секции/Выделение подробного представления

Вы можете добавлять «разделы» (sections) для группировки связанной информации в модели в форме детализации, используя атрибут fieldsets .

В модели BookInstance мы имеем информацию соответствия конкретной книги (т.е. name, imprint, and id) и датой когда она вновь станет доступной (status, due_back). Мы можем добавить их  в разные секции, добавив текст жирным шрифтом в наш BookInstanceAdmin класс. 

@admin.register(BookInstance)
class BookInstanceAdmin(admin.ModelAdmin):
    list_filter = ('status', 'due_back')

    fieldsets = (
        (None, {
            'fields': ('book','imprint', 'id')
        }),
        ('Availability', {
            'fields': ('status', 'due_back')
        }),
    )

Каждая секция имеет свой заголовок (или None, если заголовок не нужен) и ассоциированный кортеж полей в словаре — формат сложный для описания, но относительно простой для понимания, если вы посмотрите на фрагмент кода, представленный выше.

Перезапустите сайт и перейдите к списку экземпляров; форма должна отображаться следующим образом:

Встроенное редактирование связанных записей

Иногда бывает полезно иметь возможность добавлять связанные записи одновременно. Например, имеет смысл иметь как информацию о книге, так и информацию о конкретных копиях, которые вы получили на той же странице подробностей. К примеру, вполне логично получить и информацию о книге, и информацию о конкретных копиях, зайдя на страницу детализации.

Вы можете это сделать, объявив inlines, и указав тип TabularInline (горизонтальное расположение) или  StackedInline (вертикальное расположение, так же как и в модели по умолчанию). Вы можете добавить  BookInstance информацию в подробное описание  Book , добавив строки, представленные ниже и располагающиеся рядом с  BookAdmin: 

class BooksInstanceInline(admin.TabularInline):
    model = BookInstance

@admin.register(Book)
class BookAdmin(admin.ModelAdmin):
    list_display = ('title', 'author', 'display_genre')
    inlines = [BooksInstanceInline]

Попробуйте перезапустить приложение, а затем взгляните на представление книги — внизу вы должны увидеть экземпляры книги, относящиеся к этой книге:

В этом случае, всё, что мы сделали — объявили наш встроенный класс tablular, который просто добавляет все поля из встроенной модели. Вы можете указать все виды дополнительной информации для макета, включая отображаемые поля, их порядок, независимо от того, являются ли они только для чтения или нет, и т. д. (См. TabularInline для получения дополнительной информации). 

Примечание: В этой функции есть некоторые неприятные ограничения! На скриншоте выше у нас есть три существующих экземпляра книги, за которыми следуют три поля для новых экземпляров книги (которые очень похожи!). Было бы лучше НЕ иметь лишних экземпляров книг по умолчанию и просто добавить их с помощью ссылки Add another Book instance или иметь возможность просто перечислять BookInstances как нечитаемые здесь ссылки. Первый вариант можно сделать, установив extra атрибут в 0 в модели BookInstanceInline, попробуйте сами.

Мы многое изучили в этом разделе и теперь настало время вам самостоятельно попробовать несколько вещей:

1. Для представления списка BookInstance , добавьте код  для отображения книги, статуса, даты возврата, и id (вместо значения по умолчанию возвращаемого  __str__() ).
2. Добавьте встроенный список перечня Book в представление списка Author , используя тот же самый подход, который мы применили для Book/BookInstance.

Вот и всё! Теперь вы узнали, как настроить сайт администрирования как в самой простой, так и в улучшенной форме, о создании суперпользователя и о том, как перемещаться по сайту администратора, просматривать, удалять и обновлять записи. По пути вы создали множество книг, экземпляров, жанров и авторов, которые мы сможем перечислить и отобразить, как только мы создадим собственный вид и шаблоны.

Django введение — Изучение веб-разработки

В первой статье о Django мы отвечаем на вопрос «Что такое Django?» и даём обзор того, что делает его особенным. Мы опишем основные функции, в том числе некоторые из расширенных функций, которые у нас не будет времени подробно рассмотреть в этом модуле. Мы также покажем вам некоторые основные строительные блоки приложения Django (хотя на данный момент у вас ещё не будет среды разработки для тестирования).

Django — это высокоуровневый Python веб-фреймворк, который позволяет быстро создавать безопасные и поддерживаемые веб-сайты. Созданный опытными разработчиками, Django берёт на себя большую часть хлопот веб-разработки, поэтому вы можете сосредоточиться на написании своего веб-приложения без необходимости изобретать велосипед. Он бесплатный и с открытым исходным кодом, имеет растущее и активное сообщество, отличную документацию и множество вариантов как бесплатной, так и платной поддержки.

Django помогает писать программное обеспечение, которое будет:

Полным

Django следует философии «Всё включено» и предоставляет почти всё, что разработчики могут захотеть сделать «из коробки». Поскольку всё, что вам нужно, является частью единого «продукта», всё это безупречно работает вместе, соответствует последовательным принципам проектирования и имеет обширную и актуальную документацию.

Разносторонним

Django может быть (и был) использован для создания практически любого типа веб-сайтов — от систем управления контентом и wiki до социальных сетей и новостных сайтов. Он может работать с любой клиентской средой и может доставлять контент практически в любом формате (включая HTML, RSS-каналы, JSON, XML и т. д.). Сайт, который вы сейчас читаете, создан с помощью Django!

Хотя Django предоставляет решения практически для любой функциональности, которая вам может понадобиться (например, для нескольких популярных баз данных, шаблонизаторов и т. д.), внутренне он также может быть расширен сторонними компонентами, если это необходимо.

Безопасным

Django помогает разработчикам избежать многих распространённых ошибок безопасности, предоставляя фреймворк, разработанный чтобы «делать правильные вещи» для автоматической защиты сайта. Например, Django предоставляет безопасный способ управления учётными записями пользователей и паролями, избегая распространённых ошибок, таких как размещение информации о сеансе в файлы cookie, где она уязвима (вместо этого файлы cookie содержат только ключ, а фактические данные хранятся в базе данных) или непосредственное хранение паролей вместо хэша пароля.

Хэш пароля — это значение фиксированной длины, созданное путём обработки пароля через криптографическую хэш-функцию. Django может проверить правильность введённого пароля, пропустив его через хэш-функцию и сравнив вывод с сохранённым значением хэша. Благодаря «одностороннему» характеру функции, даже если сохранённое хэш-значение скомпрометировано, злоумышленнику будет сложно определить исходный пароль.

Django, по умолчанию, обеспечивает защиту от многих уязвимостей, включая SQL-инъекцию, межсайтовый скриптинг, подделку межсайтовых запросов и кликджекинг (см. Website security для получения дополнительной информации об этих атаках).

Масштабируемым

Django использует компонентную “shared-nothing” архитектуру (каждая её часть  независима от других и, следовательно, может быть заменена или изменена, если это необходимо). Чёткое разделение частей означает, что Django может масштабироваться при увеличении трафика, путём добавления оборудования на любом уровне: серверы кеширования, серверы баз данных или серверы приложений. Одни из самых загруженных сайтов успешно масштабировали Django (например, Instagram и Disqus, если назвать только два из них).

Удобным в сопровождении

Код Django написан с использованием принципов и шаблонов проектирования, которые поощряют создание поддерживаемого и повторно используемого кода. В частности, в нём используется принцип «Don’t Repeat Yourself» (DRY, «не повторяйся»), поэтому нет ненужного дублирования, что сокращает объём кода. Django также способствует группированию связанных функциональных возможностей в повторно используемые «приложения» и, на более низком уровне, группирует связанный код в модули (в соответствии с шаблоном Model View Controller (MVC)).

Переносным

Django написан на Python, который работает на многих платформах. Это означает, что вы не привязаны к какой-либо конкретной серверной платформе и можете запускать приложения на многих версиях Linux, Windows и Mac OS X. Кроме того, Django хорошо поддерживается многими веб-хостингами, которые часто предоставляют определённую инфраструктуру и документацию для размещения сайтов Django.

Django был разработан в период с 2003 по 2005 год командой, которая занималась созданием и обслуживанием газетных веб-сайтов. После создания нескольких сайтов, команда начала повторно использовать множество общего кода и шаблонов проектирования. Этот общий код эволюционировал в веб-фреймворк, который превратился в проект «Django» с открытым исходным кодом в июле 2005 года.

Django продолжает расти и улучшаться с момента его первого релиза (1.0) в сентябре 2008 года до недавно выпущенной версии 3.1 (2020). В каждой версии добавлены новые функциональные возможности и исправлены ошибки, начиная от поддержки новых типов баз данных, шаблонизаторов и кеширования, до добавления «общих» функций просмотра и классов (уменьшающих объём кода, который разработчики должны писать для ряда программных задач).

Примечание: Ознакомьтесь с примечаниями к версии на сайте Django, чтобы увидеть что изменилось в последних версиях и как много работы было проделано, чтобы улучшить Django.

Django — это процветающий совместный проект с открытым исходным кодом, в котором заняты многие тысячи пользователей и участников. Несмотря на то, что у него всё ещё есть некоторые особенности, которые отражают его происхождение, Django превратился в универсальный фреймворк, способный разрабатывать веб-сайты любого типа.

Нет никаких доступных и окончательных оценок популярности серверных фреймворков (хотя сайты наподобие Hot Framework и пытаются оценить популярность, используя такие механизмы, как подсчёт количества проектов на GitHub и вопросов на StackOverflow для каждой платформы). Лучший вопрос — «достаточно ли Django популярен», чтобы избежать проблем непопулярных платформ. Продолжает ли он развиваться? Можете ли вы получить помощь, если вам нужно? Найдёте ли вы оплачиваемую работу, если изучите Django?

Основываясь на количестве крупных сайтов, которые используют Django, количестве участников и количестве людей, предоставляющих как бесплатную, так и платную поддержку, можно ответить: да, Django — популярный фреймворк!

Django используют такие крупные сайты, как Disqus, Instagram, Knight Foundation, MacArthur Foundation, Mozilla, National Geographic, Open Knowledge Foundation, Pinterest и Open Stack (источник: обзорная страница Django).

Веб-фреймворки часто можно поделить на «гибкие» и «негибкие».

Негибкие — это те, у которых есть «правильный путь» для решения какой-либо конкретной задачи. Они часто поддерживают быстрое развёртывание в определённой области (решение проблем определённого типа), потому что правильный способ сделать что-либо обычно хорошо понимается и хорошо документируется. Однако они могут быть менее гибкими при решении проблем за пределами их основной сферы и, как правило, предлагают меньше вариантов того, какие компоненты и подходы они могут использовать.

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

Django «умеренно гибкий» и, следовательно, обеспечивает «лучшее из обоих миров». Он предоставляет набор компонентов для обработки большинства задач веб-разработки и один (или два) предпочтительных способа их использования. Однако такая архитектура Django означает, что вы обычно можете выбирать из нескольких различных опций или при необходимости добавлять поддержку для совершенно новых.

На традиционном информационном веб-сайте веб-приложение ожидает HTTP-запросы от веб-браузера (или другого клиента). Когда запрос получен, приложение разрабатывает то, что необходимо на основе URL-адреса и, возможно, данных в POST или GET запросах. В зависимости от того, что требуется, далее он может читать или записывать информацию из базы данных или выполнять другие задачи, необходимые для удовлетворения запроса. Затем приложение вернёт ответ веб-браузеру, часто динамически создавая HTML-страницу для отображения в браузере, вставляя полученные данные в HTML-шаблон.

Веб-приложения, написанные на Django, обычно группируют код, который обрабатывает каждый из этих шагов, в отдельные файлы:

• URLs: Хотя можно обрабатывать запросы с каждого URL-адреса с помощью одной функции, гораздо удобнее писать отдельную функцию для обработки каждого ресурса. URL-маршрутизатор используется для перенаправления HTTP-запросов в соответствующее представление на основе URL-адреса запроса. Кроме того, URL-маршрутизатор может извлекать данные из URL-адреса в соответствии с заданным шаблоном и передавать их в соответствующую функцию отображения (view) в виде аргументов.
• View: View (англ. «отображение») — это функция обработчика запросов, которая получает HTTP-запросы и возвращает ответы. Функция view имеет доступ к данным, необходимым для удовлетворения запросов, и делегирует ответы в шаблоны через модели.
• Models: Модели представляют собой объекты Python, которые определяют структуру данных приложения и предоставляют механизмы для управления (добавления, изменения, удаления) и выполнения запросов в базу данных.
• Templates: Template (англ. «шаблон») — это текстовый файл, определяющий структуру или разметку страницы (например HTML-страницы), с полями для подстановки, которые используются для вывода актуального содержимого. View может динамически создавать HTML-страницы, используя HTML-шаблоны и заполняя их данными из модели (model). Шаблон может быть использован для определения структуры файлов любых типов, не обязательно HTML.

Примечание: Django реализует уровневую архитектуру «Model View Template (MVT)».([0-9]+)/$’, views.best),
]

Объект urlpatterns является списком функций path() и/или re_path() (в Python списки определяются с помощью квадратных скобок, внутри которых элементы разделены запятыми и могут содержать необязательную завершающую запятую. Например: [item1, item2, item3,]).

Первый аргумент в обоих методах — маршрут (шаблон), который будет сопоставлен. В методе path() угловые скобки используются для определения частей URL-адреса, которые будут захвачены и переданы в функцию отображения (view) в качестве именованных аргументов. Функция re_path() использует гибкий подход к сопоставлению с шаблоном, известный как регулярное выражение. Мы поговорим об этом в следующей статье!

Второй аргумент — это ещё одна функция, которая будет вызываться при сопоставлении шаблона. Обозначение views.book_detail указывает, что функция называется book_detail() и может быть обнаружена в модуле с именем views (т.е. внутри файла с именем views.py).

Обработка запроса (views.py)

Отображения (views) — это сердце веб-приложения, принимающего HTTP-запросы от веб-клиентов и возвращающего HTTP-ответы. Между этим они используют другие ресурсы фреймворка для доступа к базам данных, шаблонам визуализации и т. д.  

В приведённом ниже примере показана минимальная функция представления index(), которая могла быть вызвана нашим сопоставителем URL-адресов в предыдущем разделе. Как и все функции отображения (view), она получает объект HttpRequest в качестве параметра (request) и возвращает объект HttpResponse. В этом случае мы ничего не делаем с запросом, и наш ответ просто возвращает жёстко запрограммированную строку. Мы покажем вам запрос, который делает что-то более интересное в следующем разделе.

from django.http import HttpResponse

def index(request):
    
    
    
    return HttpResponse('Hello from Django!')

Примечание: Немного Python:

• Модули Python это библиотеки функций, сохранённые в различных файлах, которые мы можем использовать в нашем коде. Здесь мы импортируем только объект HttpResponse из модуля django.http чтобы использовать его в нашем отображении (view): from django.http import HttpResponse . Также есть другие способы импортирования некоторых или всех объектов модуля.
• Функции объявляются с помощью ключевого слова def, как показано выше, с именованными параметрами, перечисленными в скобках после имени функции; строка завершается двоеточием. Заметьте, что следующие строки содержат отступы.  Отступы важны, так как они определяют, какие строки кода находятся внутри конкретного блока (обязательные отступы — это ключевая особенность Python и одна из причин, почему код на Python так легко читать).

Отображения (view) обычно содержатся в файле views.py.

Определение данных модели (models.py)

Веб-приложения Django обрабатывают и запрашивают данные через объекты Python, называемые моделями. Модели определяют структуру хранимых данных, включая типы полей и, возможно, их максимальный размер, значения по умолчанию, параметры списка выбора, текст справки для документации, текст меток для форм и т. д. Определение модели не зависит от используемой базы данных — ваши модели будут работать в любой из них. После того как вы выбрали базу данных, которую хотите использовать, вам не нужно напрямую обращаться к ней — вы просто пишете свою структуру модели и другой код, а Django выполняет всю «грязную работу» по обращению к базе данных за вас.

В приведённом ниже фрагменте кода показана очень простая модель Django для объекта Team. Класс Team наследуется от класса models.Model. Он определяет имя команды и командный уровень в качестве полей символов и задаёт максимальное количество символов, которые могут быть сохранены для каждой записи. Team_level может быть одним из нескольких значений, поэтому мы определяем его как поле выбора и предоставляем сопоставление между отображаемыми вариантами и хранимыми данными вместе со значением по умолчанию.

from django.db import models

class Team(models.Model):
    team_name = models.CharField(max_length=40)

    TEAM_LEVELS = (
        ('U09', 'Under 09s'),
        ('U10', 'Under 10s'),
        ('U11', 'Under 11s'),
        ...  
    )
    team_level = models.CharField(max_length=3,choices=TEAM_LEVELS,default='U11')

Примечание: Немного Python:

• Python поддерживает «объектно-ориентированное программирование», то есть стиль программирования, в котором мы организуем наш код в объекты, которые включают связанные данные и функции для работы с этими данными. Объекты также могут наследовать / расширять / выводить из других объектов, позволяя использовать одинаковое поведение между связанными объектами. В Python мы используем ключевое слово class, чтобы определить «скелет» для объекта. Мы можем создать несколько конкретных экземпляров типа объекта на основе модели в классе.

  Так, например, мы имеем класс Team, который происходит от класса Model. Это означает, что эта модель будет содержать все методы модели, но мы также можем дать ей специализированные возможности. В нашей модели мы определяем поля нашей базы данных, в которой будем хранить данные, присваивая им конкретные имена. Django использует эти определения, включая имена полей, для создания основной базы данных.

Запросы данных (views.py)

Модель Django предоставляет простой API запросов для поиска в базе данных. Поиск может осуществляться по нескольким полям одновременно, используя различные критерии (такие как exact («точный»), case-insensitive («без учёта регистра»), greater than («больше чем») и т. д.), и может поддерживать сложные выражения (например, вы можете указать поиск в командах U11, у которых есть имя команды, начинающееся с «Fr» или заканчивается на «al»).

Фрагмент кода показывает функцию view (обработчик ресурсов) для отображения всех команд U09. Выделенная жирным строка показывает, как мы можем использовать модель API-запросов для того, чтобы отфильтровать все записи, где поле team_level в точности содержит текст ‘U09’ (обратите внимание, как эти критерии передаются функции filter() в качестве аргумента с именем поля и типом соответствия, разделённым двойным подчёркиванием: team_level__exact). 

from django.shortcuts import render
from .models import Team

def index(request):
    list_teams = Team.objects.filter(team_level__exact="U09")
    context = {'youngest_teams': list_teams}
    return render(request, '/best/index.html', context)

Данная функция использует функцию render() для того, чтобы создать HttpResponse, который будет отправлен назад браузеру. Эта функция является ярлыком; она создаёт HTML-файл, комбинируя указанный HTML-шаблон и некоторые данные для вставки в шаблон (предоставляется в переменной с именем «context»). В следующем разделе мы  покажем как данные вставляются в шаблон для создания HTML-кода.

Вывод данных (HTML-шаблоны)

Системы шаблонов позволяют указать структуру выходного документа, используя заполнители для данных, которые будут вставлены при генерировании страницы. Шаблоны часто используются для создания HTML, но также могут создавать другие типы документов. Django «из коробки» поддерживает как собственную систему шаблонов, так и другую популярную библиотеку Python под названием Jinja2 (она также может быть использована для поддержки других систем, если это необходимо).

Фрагмент кода показывает, как может выглядеть HTML-шаблон, вызванный функцией  render() из предыдущего раздела. Этот шаблон был написан с предположением, что во время отрисовки он будет иметь доступ к переменной списка, названной youngest_teams (содержащейся в контекстной переменной внутри функции render() выше). Внутри скелета HTML мы имеем выражение, которое сначала проверяет, существует ли переменная youngest_teams, а затем повторяет её в цикле for. При каждом повторе шаблон отображает значение team_name каждой команды в элементе <li>.

## filename: best/templates/best/index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Home page</title>
</head>
<body>
  {% if youngest_teams %}
    <ul>
      {% for team in youngest_teams %}
        <li>{{ team.team_name }}</li>
      {% endfor %}
    </ul>
  {% else %}
    <p>No teams are available.</p>
  {% endif %}
</body>
</html>

В предыдущих разделах показаны основные особенности, которые вы будете использовать почти в каждом веб-приложении: сопоставление URL-адресов, отображение, модели и шаблоны. Также Django предоставляет несколько других вещей:

• Формы: HTML-формы используются для сбора пользовательских данных для обработки на сервере. Django упрощает создание, проверку и обработку формы.
• Аутентификация пользователя и разрешения: Django включает надёжную систему аутентификации и авторизации пользователей, которая была построена с учётом безопасности.
• Кеширование: Создание динамического контента намного более интенсивно (и медленнее), чем обслуживание статического содержимого. Django обеспечивает гибкое кеширование, чтобы вы могли хранить всю или часть отображаемой страницы, для того, чтобы она не вызывалась повторно, за исключением случаев, когда это необходимо.
• Админ-панель: Административная панель в Django включена по умолчанию при создании приложения с использованием основного каркаса. Это упрощает управление админкой администраторам сайта для создания, редактирования и просмотра любых данных на вашем сайте.
• Сериализация данных (преобразование в последовательную форму): Django упрощает сериализацию и обслуживание ваших данных в таких форматах как XML или JSON. Это может быть полезно при создании веб-сервисов (веб-сайтов, которые исключительно служат для использования данных другими приложениями или сайтами и сами ничего не отображают) или при создании веб-сайта, на котором клиентский код обрабатывает весь рендеринг данных.

Поздравляем, вы завершили первый шаг в своём путешествии по Django! Теперь вы должны понимать основные преимущества Django, немного его истории, и примерно как может выглядеть каждая из основных частей приложения Django. Вы должны также изучить несколько вещей о языке программирования Python, включая синтаксис списков, функций и классов.

Вы уже видели код на Django выше, но в отличие от клиентского кода вам нужно настроить среду разработки для её запуска. Это наш следующий шаг.

Введение · HonKit

Это руководство распространяется под международной лицензией Creative Commons Attribution-ShareAlike 4.0
Чтобы ознакомиться с содержанием этой лицензии, посети: https://creativecommons.org/licenses/by-sa/4.0/

Вступительное слово

Добро пожаловать в руководство Django Girls! Мы рады тебя здесь видеть 🙂 В этом руководстве мы заглянем за кулисы веб-технологий и дадим
базовое представление о тех вещах, которые собираются в общую картину веба таким, каким мы его знаем.

Как и с любой незнакомой темой – это будет приключением. Но не волнуйся, тебе уже хватило смелости оказаться здесь, так что всё будет хорошо 🙂

Введение

Ты когда-нибудь чувствовала, что мир становится все более и более технологичным, в то время как ты остаёшься где-то позади? Ты задумывалась о том, как создать веб-сайт, но мотивации начать никогда не хватало? Приходило ли тебе в голову, что мир программного обеспечения слишком сложен, чтобы пробовать сделать что-то самой?

Тогда у нас есть для тебя хорошие новости! Программирование – не такая уж сложная задача, как кажется, и мы покажем тебе, как весело это может быть.

Это руководство не превратит тебя волшебным образом в программиста. Если ты хочешь добиться мастерства, то потребуются месяцы, а может быть и годы обучения и практики. Однако, мы хотим показать тебе, что программирование или создание веб-сайтов не настолько сложная задача как может показаться. Мы постараемся объяснить все настолько хорошо, насколько сможем, чтобы ты не чувствовала себя запуганной техническими деталями.

Надеемся, что ты полюбишь информационные технологии также, как мы любим их!

Что ты узнаешь из этого руководства?

После прохождения руководства у тебя будет простое работающее веб-приложение: свой собственный блог. Мы покажем, как разместить его онлайн, чтобы другие увидели твою работу!

Он будет выглядеть следующим образом (более или менее):

Если ты будешь работать над учебником самостоятельно и без тренера, который смог бы помочь при необходимости, то у нас есть для тебя чат: . Мы попросили наших тренеров и успешно прошедших обучение участников заглядывать туда время от времени и помогать остальным! Не стесняйся задавать там свои вопросы!

Хорошо, давай начнем с начала…

Прохождение руководства дома

Принимать участие в воркшопе Django Girls – это потрясающе, но мы понимаем, что не всегда есть такая возможность. Поэтому мы приветствуем прохождение
данного руководства дома. В настоящий момент мы готовим видео, которое поможет следовать руководству самостоятельно. Работа над ними ещё не закончена,
но все больше и больше тем скоро будут разобраны на YouTube-канале Coding is for girls.

Сотрудничество и дополнительная информация

Это руководство поддерживается DjangoGirls. Если ты нашла ошибки или хочешь обновить информацию, пожалуйста, следуй этим рекомендациям.

Хочешь помочь с переводом руководства на другие языки?

В настоящее время перевод координируется через платформу crowdin.com:

https://crowdin.com/project/django-girls-tutorial

Если твоего языка нет в списке на crowdin, пожалуйста, дай нам знать, чтобы мы могли его добавить.

Эффективный Django. Часть 1 / Хабр

Представляю вам перевод статей о Django с сайта effectivedjango.com. Наткнулся я на этот сайт во время изучения данного фреймворка. Информация размещенная на этом ресурсе показалась мне полезной, но так как нигде не нашел перевода на русский, решил сделать сие доброе дело сам. Этот цикл статей, как мне думается, будет полезен веб-разработчикам, которые делают только первые шаги в изучении Django.

---

• Введение
• Эффективный Django. Руководство
• Тестирование в Django
• Понимание Middleware’ов
• Базы данных и модели
• Представления-классы (CBV)
• Формы

Django — это популярный, мощный фреймворк на языке Python. Он имеет множество «

батареек

«, и позволяет

сразу начать разработку

. Однако вся эта мощь означает, что вы можете написать низкопробный код, который будет казаться рабочим. Так что же подразумевается под Эффективным Django? Под Эффективным Django будем понимать использование Django таким образом, чтобы написанный код был

связным

,

тестируемым

и

масштабируемым

. Что же каждое из этих слов значит?

«Связный» код — это код, который сосредоточен на выполнении одной вещи, только одной единственной вещи. Это значит, что когда вы пишете функцию или метод — написанный вами код должен делать что-то одно и делать это хорошо.

Это непосредственно относится к написанию тестируемого кода: код, который делает много вещей, достаточно часто является чересчур сложным для тестирования. Когда я ловлю себя на мысли: «Хорошо, этот кусок кода слишком сложен, чтобы писать для него тесты — это просто не стоит потраченных усилий» — вот сигнал к тому, чтобы вернутся назад и сосредоточиться на упрощении. Тестируемый код — такой код, который позволяет просто писать для него тесты; код, в котором легко найти проблемы.

И наконец, мы хотим писать масштабируемый код. Это означает не просто масштабировать его в терминах исполнения, но так же увеличивать в терминах команды и командного понимания. Хорошо протестированные приложения проще для понимания другими (и проще для изменения ими), что подразумевает большую возможность улучшить ваше приложение, путем добавления новых инженеров.

Моя цель — убедить вас в важности этих принципов, и предоставить примеры того, как следуя им, построить более стойкое Django-приложение. Я собираюсь последовательно пройти через процесс построения приложения для управления контактами, рассказывая про решения и стратегию тестирования, которые я использую.

Эти документы являются сочетанием заметок и примеров подготовленных для PyCon 2012, PyOhio 2012, и PyCon 2013, а также для web-разработки Eventbrite. Я все еще работаю над объединением их в один документ, но надеюсь вы найдете их полезными.

Примеры кода для этого руководства доступны на github’е. Отзывы, предложения и вопросы можете присылать на [email protected].

Этот документ доступен на сайте, а также в форматах PDF и EPub.

Видео этого руководства с PyCon можно посмотреть на YouTube.

1.1. Ваша среда разработки

Когда ведется разговор о вашей среде разработки, существует три важных факта, которые необходимо иметь в виду:

изоляция

,

предопределенность

и

сходство

. Каждый из них важен и все они взаимодействуют друг с другом согласованно.

Изоляция означает, что вы не сможете случайно воспользоватся инструментами или пакетами установленными вне вашего окружения. Это особенно важно, когда подобное происходит с чем-то, похожим на пакеты Python с расширениями написанными на C: если вы используете что-то установленное на системном уровне и не знаете об этом, то при развертывании или распространении своего кода вы можете обнаружить, что он работает не так как предполагалось. Инструменты наподобие virtualenv могут помочь создать нечто похожее на изолированную среду.

Ваша среда предопределена, если вы уверены в том, на какую версию ваших зависимостей вы полагаетесь и сможете ли вы наверняка воспроизвести системное окружение.

И на конец, сходство с производственной средой или средой сервера разработки означает, что везде установлена одна и та же операционная система (возможно даже одинаковый выпуск) и вы используете одинаковые инструменты как для конфигурирования вашей среды разработки, так и для конфигурирования вашей производственной среды. Это отнюдь не необходимость, но если вы строите большое и сложное программное обеспечение — сходство будет полезно для уверенности в том, что все проблемы, которые вы можете увидеть на «боевом» сервере, воспроизводимы в той среде, где вы ведете разработку. К тому же сходство ограничивает область исследования вашего кода.

1.1.1. Изоляция

• Мы хотим избежать использования неизвестных зависимостей или неизвестных версий.
• virtualenv предоставляет простой путь для работы над проектом, без использования системных site-packages.

1.1.2. Предопределенность

• Предопределенность означает управление зависимостями.
• Выберете один из инструментов и используйте как при разработке, так на «боевом» сервере:
• Определите точные версии зависимостей.

Вы можете точно определить версии используя либо версию пакета на PyPI, либо же определенную ревизию (SHA в git, номер ревизии в Subversion и т. д.). Это гарантирует вам возможность получить в точности те же версии пакетов, которые вы используете при тестировании.

1.1.3. Сходство

• Работа в среде, похожей на ту, где вы будете разворачивать ваше приложение и пытаться обнаружить проблемы.
• Если вы разрабатываете что-то, требующее дополнительных сервисов — сходство становится еще более важным.
• Vagrant — это инструмент для управления виртуальными машинами, позволяющий вам легко создавать окружение отделенное от вашего повседневного окружения.

1.2. Настройка вашего окружения

1.2.1. Создание чистого рабочего пространства

Примечание переводчика:
Для начала создадим каталог (tutorial), в котором будем работать:

~$ mkdir tutorial
~$ cd tutorial
~/tutorial$ mkdir venv project

В каталоге venv будет находится наше виртуальное окружение, а в каталоге project — Django-проект

~/tutorial$ virtualenv --prompt="(venv:tutorial)" ./venv/

New python executable in ./venv/bin/python
Installing setuptools............done.
Installing pip...............done.

~/tutorial$ source ./venv/bin/activate
(venv:tutorial)~/tutorial$

1.2.2. Создание файла зависимостей

Создайте файл

requirements.txt

в директории

tutorial

с единственной строкой (зависимостью) в нем:

Django==1.6.7

Примечание переводчика:
В случае, если вы хотите использовать последнюю версию Django (1.7 — на момент написания перевода) — вместо строки Django==1.6.7 оставьте просто Django — pip установит последнюю доступную версию.

1.2.3. Установка зависимостей

А теперь мы можем использовать

pip

для установки зависимостей:

(venv:tutorial)~/tutorial$ pip install -U -r requirements.txt

Downloadping/unpacking Django==1.6.7 (from -r requirements.txt (line 1))
  Downloading Django-1.6.7.tar.gz (6.6MB): 6.6MB downloaded
  Running setup.py egg_info for package Django

    warning: no previously-included files matching ’__pycache__’ found under directory ’*’
    warning: no previously-included files matching ’*.py[co]’ found under directory ’*’
Installing collected packages: Django
  Running setup.py install for Django
    changing mode of build/scripts-2.7/django-admin.py from 644 to 755

    warning: no previously-included files matching ’__pycache__’ found under directory ’*’
    warning: no previously-included files matching ’*.py[co]’ found under directory ’*’
    changing mode of /home/nathan/p/edt/bin/django-admin.py to 755
Successfully installed Django
Cleaning up...

1.3. Начало проекта Django

Когда здание находится в процессе постройки, строительные леса часто используются для поддержания структуры до того как строительство будет завершено. Строительные леса могут быть временными или они могут служить частью фундамента здания, но несмотря на это, они представляют некоторую поддержку когда вы только начинаете работу.

Django, как и многие web-фреймворки, представляет скаффолдинг для вашей разработки. Это происходит при помощи принятия решений и предоставления отправной точки для вашего кода, что позволяет вам сосредоточится на проблеме, которую вы пытаетесь решить, а не на том, как разобрать HTTP-запрос. Django предоставляет скаффолдинг как для работы с HTTP, так и для работы с файловой системой.

HTTP-скаффолдинг управляет, например, преобразованием HTTP-запроса в объект языка Python, а также предоставляет инструменты для более простого создания серверных ответов. Скаффолдинг файловой системы иной: это набор соглашений по организации вашего кода. Эти соглашения облегчают добавление новых инженеров в проект, так как инженеры (гипотетически) уже понимают как организован код. В терминах Django, проект — это конечный продукт, и он объединяет внутри себя одно или несколько приложений. В Django 1.4 было изменено то, как проекты и приложения размещаются на диске, что облегчило разъединение и повторное использование приложений в разных проектах.

1.3.1. Создание проекта

Django устанавливает в систему скрипт

django-admin.py

для обработки задач скаффолдинга. Для создания файлов проекта используется задача

startproject

. Мы определим имя проекта и имя директории, в которой хотим разместить проект. Так как, мы уже находимся в изолированной среде, можно просто написать:

Примечание переводчика:
Перейдем директорию ~/tutorial/project/ и в дальнейшем будем работать только из этой директории (под $ далее будем подразумевать ~/tutorial/project/$):

(venv:tutorial)~/tutorial/$ cd project

(venv:tutorial)$ django-admin.py startproject addressbook .

Созданный проект имеет следующую структуру

manage.py
./addressbook
    __init__.py
    settings.py
    urls.py
    wsgi.py

1.3.2. Скаффолдинг проекта

• manage.py — является ссылкой на скрипт django-admin, но с уже предустановленными переменными окружения, указывающими на ваш проект, как для чтения настроек оттуда, так и для управления им при необходимости;
• settings.py — здесь находятся настройки вашего проекта. Файл уже содержит несколько разумных настроек, но база данных не указана;
• urls.py — содержит URL’ы для маппирования (отображения) представлений: мы вскоре (в дальнейших главах) поговорим об этом подробнее;
• wsgi.py — это WSGI обёртка для вашего приложения. Этот файл используется сервером разработки Django и возможно другими контейнерами, такими как mod_wsgi, uwsgi и др. на «боевом» сервере.

1.3.3. Создание приложения

(venv:tutorial)$ python ./manage.py startapp contacts

Созданное приложение имеет следующую структуру:

./contacts
    __init__.py
    models.py
    tests.py
    views.py

• Начиная с Django 1.4, приложения размещаются внутри пакета с проектом. Это замечательное улучшение, особенно когда приходит время разворачивать проект на «боевом» сервере;
• models.py будет содержать Django ORM-модели для вашего приложения;
• views.py будет содержать код представлений;
• tests.py будет содержать написанные вами модульные и интеграционные тесты.
• Django 1.7: admin.py будет содержать модель для административного интерфейса.
• Django 1.7: migrations/ содержит файлы миграций

Примечание переводчика:
На текущий момент наша директория ~/tutorial/ содержит файл зависимостей (requirements.txt), директорию с виртуальным окружением (venv/), один проект (project/addressbook), одно приложение (project/contacts) и имеет следующее содержание:

~/tutorial/
	requirements.txt
	venv/
		...
	project/
		manage.py
		addressbook/
			__init__.py
			settings.py
			urls.py
			wsgi.py
		contacts/
			__init__.py
			models.py
			tests.py
			views.py

2.1. Конфигурирование базы данных

Django поддерживает «из коробки» MySQL, PostgreSQL, SQLite3 и Oracle.

SQLite3

входит в состав Python начиная с версии 2.5, так что мы будем использовать его в нашем проекте (для простоты). Если вы хотите, к примеру, использовать MySQL, то нужно добавить

mysql-python

в ваш

requirements.txt

.

Для того чтобы в качестве базы данных использовать SQLite, отредактируйте определение DATABASES в файле addressbook/settings.py. Файл settings.py содержит настройки Django для нашего проекта. В нем есть несколько настроек, которые вы обязаны указать — например DATABASES — а так же другие, необязательные, настройки. Django устанавливает некоторые настройки сам, когда генерирует проект. Документация содержит полный список настроек. К тому же вы можете добавить свои собственные настройки, если это необходимо.

Для использования SQLite нам нужно указать движок (ENGINE) и имя базы (NAME). SQLite интерпертирует имя базы как имя файла для базы данных:

DATABASES = {
    'defaults': {
	    'ENGINE': 'django.db.backends.sqlite3,' # ’postgresql_psycopg2’, ’mysql’, ’sqlite3’ or ’oracle'.
		'NAME': os.path.join(BASE_DIR, 'address.db'),
		'USER': '',     # Not used with sqlite3.
		'PASSWORD': '', # Not used with sqlite3.
		'HOST': '',     # Set to empty string for localhost. Not used with sqlite3.
		'PORT': '',     # Set to empty string for default. Not used with sqlite3.
	}
}

Заметьте, что движок базы данных указан строкой, а не прямой ссылкой на объект Python. Это сделано по той причине, что файл настроек должен быть легко импортирован

не вызывая сторонних эффектов

. Вы должны избегать добавления вызовов import в этот файл.

Вам редко придется непосредственно импортировать файл настроек: Django импортирует его за вас, и делает настройки доступными как django.conf.settings. Вы, как правило, импортируете настройки из django.conf:

from django.conf import settings

2.2. Создание модели

Модели Django отображают (грубо говоря) таблицы базы данных, и предоставляют место для инкапсулирования бизнес-логики. Все модели являются наследниками базового класса

Model

и содержат поля определений. Давайте создадим простую модель

Contacts

для нашего приложения в файле

contacts/models.py

:

from django.db import models

class Contact(models.Model):

    first_name = models.CharField(
        max_length=255,
    )
    last_name = models.CharField(
        max_length=255,
    )
	
    email = models.EmailField()

	def __str__(self):

	    return ' '.join([
            self.first_name,
            self.last_name,
        ])

Django предоставляет

набор полей

для отображения типов данных и различных правил валидации. К примеру,

EmailField

, который мы использовали, является отображением на колонку с типом

CharField

, но добавляет валидацию данных.

После того, как вы создали модель, необходимо дополнить вашу базу данных новыми таблицами. Команда Django syncdb смотрит установленные модели и создает (если нужно) таблицы для них:

Примечание переводчика:

Django предложит создать суперпользователя для андминки, которая включена в этой версии по умолчанию. Воспользуйтесь его предложением.

Примечание переводчика:

С версии Django 1.7 во фреймворк добавлена нативная поддержка миграций и команда syncdb объявлена устаревшей. Так что будьте так любезны, воспользуйтесь командой migrate вместо syncdb.

(venv:tutorial)$ python ./manage.py syncdb

Creating tables ...
Creating table django_admin_log
Creating table auth_permission
Creating table auth_group_permissions
Creating table auth_group
Creating table auth_user_groups
Creating table auth_user_user_permissions
Creating table auth_user
Creating table django_content_type
Creating table django_session

You just installed Django's auth system, which means you don't have any superusers defined.
Would you like to create one now? (yes/no): yes
Username (leave blank to use 'bjakushka'):
Email address: 
Password:
Password (again):
Superuser created successfully.
Installing custom SQL ...
installing indexes ...
Installed 0 object(s) from 0 fixture(s)

(venv:tutorial)$

Примечание переводчика:

Если вы используете Django версии 1.7 и выше — вывод будет следующий:

(venv:tutorial)$ python ./manage.py migrate

Opperation to perform:
    Apply all migrations: admin, contenttypes, auth, sessions
Running migrations:
    Applying contenttypes.0001_initial... OK
    Applying auth.0001_initial... OK
    Applying admin.0001_initial... OK
    Applying sessions.0001_initial... OK

(venv:tutorial)$ 

Однако нашей таблицы с контактами нигде не видно. Причина этого состоит в том, что нам нужно еще указать проекту использовать приложение.

Настройка INSTALLED_APPS содержит список приложений, используемых в проекте. Этот список содержит в себе строки, которые отображают пакеты Python. Django будет импортировать каждый из указанных пакетов, а потом смотреть модуль models. Давайте добавим наше приложение contacts в настройки проекта (addressbook/settings.py):

INSTALLED_APPS = (
  'django.contrib.admin',
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  
  'contacts',
)

После этого запустите

syncdb

снова:

Примечание переводчика:

Для Django версии 1.7 и выше вам нужно будет запустить сначала команду makemigrations — для создания миграций на основе изменений в моделях, а после этого выполнить команду migrate — для того чтобы применить созданные миграции.

(venv:tutorial)$ python ./manage.py syncdb

Creating tables ...
Creating table contacts_contact
Installing custom SQL ...
Installing indexes ...
Installed 0 object(s) from 0 fixture(s)

(venv:tutorial)$

Примечание переводчика:

Вывод для Django 1.7 и выше:

(venv:tutorial)$ python ./manage.py makemigrations

Migrations for 'contacts':
    0001_initial.py:
        - Create model Contact

(venv:tutorial)$ python ./manage.py migrate

Opperation to perform:
    Apply all migrations: admin, contenttypes, sessions, auth, contacts
Running migrations:
    Applying contacts.0001_initial... OK

(venv:tutorial)$ 

Заметьте, что Django создает таблицу с именем

contacts_contact

: по умолчанию Dj ango дает таблицам имена используя комбинацию имени приложения и имени модели. Вы можете изменить это с помощью опций модели

Meta

.

2.3. Взаимодействие с моделью

Теперь, когда модель синхронизирована с базой данных мы можем взаимодействовать с нею используя интерактивную оболочку:

(venv:tutorial)$ python ./manage.py shell
Python 2.7.3 (default, Mar 14 2014, 11:57:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from contacts.models import Contact
>>> Contact.objects.all()
[]
>>> Contact.objects.create(first_name='Nathan', last_name='Yergler')
<Contact: Nathan Yergler>
>>> Contact.objects.all()
[<Contact: Nathan Yergler>]
>>> nathan = Contact.objects.get(first_name='Nathan')
>>> nathan
<Contact: Nathan Yergler>
>>> print nathan
Nathan Yergler
>>> nathan.id
1

Здесь использовалось несколько новых штук. Во-первых, команда

manage.py shell

запускает для нас интерактивную оболочку Python’а с правильно установленными путями для Django. Если вы попробуете запустить интерпретатор Python и просто импортировать ваше приложения, будет выброшено исключение, потому что Django не знает, какие настройки использовать, и не может отобразить экземпляры модели на базу данных.

Во-вторых, здесь использовалось свойство objects нашей модели. Это менеджер модели. Так, если один экземпляр модели является аналогией для строки в базе, то менеджер модели — аналогией для таблицы. По умолчанию менеджер модели предоставляет функциональность запросов и может быть настроен. Когда мы вызываем all(), filter() или сам менеджер, возвращается объект QuerySet. QuerySet является итерируемым объектом и загружает данные из базы по необходимости.

И последнее — выше использовалось поле с именем id, которое мы не определяли в нашей модели. Django добавляет это поле как первичный ключ для модели, но только в том случае если вы сами не определили какое поле будет первичным ключом.

2.4. Написание тестов

В нашей модели определен один метод,

__str__

, так что настало время писать тесты. Метод

__str__

будет использоваться всего лишь в нескольких местах, и,

вполне возможно, полностью будет показан конечному пользователю

.

Для этого метода стоит написать тест, пока мы понимаем как он работает

. Django создал файл

tests.py

когда создавал приложение, так что мы добавим первый тест в этот файл, приложения

contacts

.

from django.test import TestCase

from contacts.models import Contact

class ContactTests(TestCase):
    """Contact model tests."""
	
    def test_str(self):
	
        contact = Contact(first_name='John', last_name='Smith')
        self.assertEquals(
            str(contact),
            'John Smith',
        )

Вы можете запустить тесты для вашего приложения используя команду

manage.py test

:

(venv:tutorial)$ python ./manage.py test

Если вы запустите это, то увидите что выполнилось около 420 тестов. Это удивляет, так как мы написали только один. Произошло это потому, что по умолчанию Django запускает тесты для всех установленных приложений. Когда вы добавляли приложение

contacts

в наш проект, то могли увидеть, что там по умолчанию были добавлены несколько встроенных приложений Django. Дополнительные 419 тестов были взяты оттуда.

Примечание переводчика:
В нашем случае (при использовании версии Django 1.6.7) предыдущий абзац несколько устарел: запустится только один тест — тот который мы создали. Вывод команды будет такой как указано ниже.

Если же вы захотите запустить тесты для определенного приложения — укажите имя приложения в команде:

(venv:tutorial)$ python manage.py test contacts

Creating test database for alias ’default’...
.
----------------------------------------------------------------------
Ran 1 tests in 0.001s

OK
Destroying test database for alias ’default’...

(venv:tutorial)$

Еще одна интересная вещь на заметку, прежде чем двигаться дальше — первая и последняя строка вывода:

Creating test database

и

Destroying test database

. Некоторым тестам необходим доступ к базе данных, и поскольку мы не хотим мешать тестовые данные с «реальными» (по разным причинам, не последней из которых является предопределенность), Django услужливо создает тестовую базу для нас, прежде чем запускать тесты. По существу, создается новая база данных, и потом запускается

syncdb

для нее. Если тестовый класс является потомком класса

TestCase

(как у нас), Django так же сбросит данные в значения по умолчанию после запуска каждого теста, так что изменения в одном из тестов не затронут другие.

2.5. Резюме

• Модель определяет поля в таблице, и содержит бизнес-логику.
• Команда syncdb создает таблицы в вашей базе данных из моделей. В Django версии 1.7 и выше вместо команды syncdb необходимо использовать сначала команду makemigrations — для создания миграций, а после этого команду migrate — для внесение изменений в базу.
• Менеджер модели позволяет вам оперировать коллекциями экземпляров: запросы, создание и т. д..
• Пишите модульные тесты для методов, которые вы добавили в модель.
• Команда управления test запускает модульные тесты на выполнение.

Примечание переводчика:
Для того чтобы протестировать наше, пока еще пустое, приложение нужно выполнить следующую команду:

(venv:tutorial)$ python ./manage.py runserver 0.0.0.0:8080

Это запустит встроенный сервер, функционал которого любезно предоставляет нам Django. В параметрах после runserver указывается ip-адрес и порт, который будет слушаться работающим сервер. В нашем случае сервер будет принимать запросы от всех ip-адресов при обращении на 8080 порт.

Я использую для разработки домашний сервер с внутренним IP 192.168.1.51. Так что для того что-бы увидеть результат работы сервера разработки в браузере я захожу по адресу http://192.168.1.51:8080/. Вы же должны подставить адрес своего сервера.

---

Как думаете, нужно ли продолжать перевод остальных глав? Оказался ли перевод для Вас полезен?

Буду рад конструктивной критике в комментариях.

Об ошибках и неточностях перевода прошу сообщать в личном сообщении.

Использованное в начале поста изображение создано как вариация изображения пользователя MaGIc2laNTern

Самый полный видеокурс по Django от установки до проекта

Язык Python можно также использовать для написания сайтов. Вот занимательный видеокурс по Django на примере создания интернет-магазина.

Вас интересует фреймворк Django? Тогда вы по адресу. Оставим библиотеки, модули и трюки позади. Разберем Django по косточкам 😉

Эта лекция является вступительной в видеокурс по Django, в ней будет рассматриваться установка необходимого софта для работы с Python и Django. Автор показывает: процесс установки Python, настройки всех переменных, установки Django через pip, а также установку IDE PyCharm и его тестовый запуск.

Чтобы начать разрабатывать свой первый проект, нужно хорошенько разобраться со структурой IDE. После структуры в ролике пойдет речь об очень важной теме: как фреймворк Django взаимодействует с пользователем, о стилях и переменных.

Данный урок будет посвящен созданию блоков функционала, разнесенного по разным файлам. Такой подход облегчит разработку и скорость работы проекта. Второй крупной темой видео будет работа с базой, инициализация и «общение» с таблицами.

В этой лекции автор расскажет о кастомизации админки и отображении записей. Попутно разъясняется синтаксис языка Python, процесс создания элементов страницы, изменения имени модели, а также проводится траблшутинг.

В этом ролике создается веб-станица на примере готового шаблона. Для понимания всего происходящего пригодятся знания основ верстки, а также сильно облегчит жизнь опыт работы с элементами Bootstrap.

На прошлых уроках была создана страница на Bootstrap, а теперь пришло время заняться логикой. Будет создана структура БД, и автор уделит значительное внимание связям между таблицами и моделями Django.

Данный урок научит создавать логику для просчета общей стоимости товара в заказе, исходя из количества, а также просчет, исходя из стоимости товаров при помощи метода save и сигнала post_save.

Автор выбирает шаблон для будущего магазина, подробно разбирает каждый из них на предмет плюсов и минусов и рассматривает основные элементы UI.

На прошлом уроке был выбран и разобран по кирпичикам шаблон, а на этом уроке будет рассматриваться наследование в шаблонах, подключение внешних HTML-файлов. Кроме того, вы научитесь использовать циклы, для получения данных из каждой записи в массиве.

https://www.youtube.com/watch?&v=PF1hh5ePcKI

Допиливание и переделка кода происходит на протяжении всего видеокурса, а в этом ролике происходит создание и добавление страницы товара. Автор показывает, как по id из url можно работать с товаром.

В этом ролике вы узнаете, как создать корзину при помощи jQuery и Ajax для интернет-магазина на Django. Поймете, как все динамические инструменты взаимодействуют с движком и между собой.

Этот урок продолжает видеокурс по Django framework, в котором будет происходить работа с Ajax по сохранению информации о товаре в БД. Будет создана модель для корзины и доработано взаимодействие фронтенда и бекенда.

Context processor – важная тема, поэтому сейчас вы научитесь создавать свой процессор для переменных, доступных со всех страниц. В лекции это показано на примере товаров в корзине.

Это последнее видео из серии про Ajax и jQuery, в котором вы узнаете, как происходит удаление товаров из корзины.

В этом видео автор показывает, как можно создать фронтенд формы для чекаута выбранного товара. Также будут рассмотрены формы Django и то, как в них можно динамически подгружать информацию.

На прошлом уроке был создан фронтенд, а здесь создается бекенд страницы чекаута для интернет-магазина. Вы научитесь пересохранять данные из модели «Товары» в корзине в модель «Товары» в заказе.

Этот видеокурс по Django посвящен запуску проекта на сервере в интернете. В качестве ОС была выбрана Ubuntu. Весь процесс подробно описан от регистрации до запуска.

Заключительная лекция курса и последняя часть по работе с удаленным сервером с рабочим проектом. Автор рассказывает, как запустить Django на сервере при помощи связки nginx + gunicorn.

А с какими трудностями столкнулись вы, работая с Django framework?

Документация Django 3.2 на русском языке | Документация Django 3.2

Рецепты 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 | Документация Django

Этот документ поможет вам начать работу с Django.

Установите Apache и

mod_wsgi ¶

Если вы просто хотите поэкспериментировать с Django, переходите к следующему
раздел; Django включает легкий веб-сервер, который вы можете использовать для
тестирования, поэтому вам не нужно настраивать Apache, пока вы не будете готовы
развернуть Django в продакшене.

Если вы хотите использовать Django на рабочем сайте, используйте Apache с
mod_wsgi.mod_wsgi работает в одном из двух режимов: встроенный
режим или режим демона. Во встроенном режиме mod_wsgi похож на
mod_perl — он встраивает Python в Apache и загружает код Python в
память при запуске сервера. Код остается в памяти на протяжении всего
жизнь процесса Apache, что приводит к значительной производительности
выигрывает по сравнению с другими серверами. В режиме демона появляется mod_wsgi
независимый процесс-демон, который обрабатывает запросы. Демон
процесс может запускаться от имени другого пользователя, чем веб-сервер, возможно
ведет к повышению безопасности.Процесс демона можно перезапустить
без перезапуска всего веб-сервера Apache, возможно,
обновление вашей кодовой базы более плавным. Проконсультируйтесь с mod_wsgi
документацию, чтобы определить, какой режим подходит для вашей установки. Делать
убедитесь, что у вас установлен Apache с активированным модулем mod_wsgi.
Django будет работать с любой версией Apache, поддерживающей mod_wsgi.

См. Как использовать Django с mod_wsgi
для получения информации о том, как настроить mod_wsgi, когда он у вас есть
установлены.

Если по какой-то причине вы не можете использовать mod_wsgi, не бойтесь: Django поддерживает многие другие
варианты развертывания.Один из них — uWSGI; оно работает
очень хорошо с nginx. Кроме того, Django следует спецификации WSGI.
( PEP 3333 ), что позволяет ему работать на различных серверных платформах.

Запустите свою базу данных¶

Если вы планируете использовать API базы данных Django, вам нужно сделать
убедитесь, что сервер базы данных запущен. Django поддерживает множество разных баз данных
серверов и официально поддерживается PostgreSQL, MariaDB, MySQL, Oracle
и SQLite.

Если вы разрабатываете небольшой проект или что-то, что не планируете внедрять в
в производственной среде SQLite, как правило, является лучшим вариантом, поскольку он не
требуют запуска отдельного сервера.Однако SQLite имеет много отличий от
другие базы данных, поэтому, если вы работаете над чем-то существенным, это
рекомендуется разрабатывать с той же базой данных, которую вы планируете использовать в
производство.

Помимо официально поддерживаемых баз есть бэкенды
предоставленные третьими сторонами, которые позволяют вам использовать другие
базы данных с Django.

Помимо серверной части базы данных, вам необходимо убедиться, что ваш Python
привязки к базе данных установлены.

• Если вы используете PostgreSQL, вам понадобится пакет psycopg2.Обратитесь к
  Примечания PostgreSQL для получения дополнительных сведений.
• Если вы используете MySQL или MariaDB, вам понадобится драйвер API БД, например mysqlclient . См. Примечания для MySQL
  backend для подробностей.
• Если вы используете SQLite, возможно, вы захотите прочитать примечания к серверной части SQLite.
• Если вы используете Oracle, вам понадобится копия cx_Oracle, но, пожалуйста,
  прочтите примечания к бэкэнду Oracle для подробностей
  относительно поддерживаемых версий Oracle и cx_Oracle .
• Если вы используете неофициальную серверную часть стороннего производителя, обратитесь к
  документация для любых дополнительных требований.

Если вы планируете использовать команду Django manage.py migrate для автоматического
создавать таблицы базы данных для ваших моделей (после первой установки Django и
создание проекта), вам необходимо убедиться, что у Django есть разрешение на создание
и изменять таблицы в базе данных, которую вы используете; если вы планируете создать вручную
таблицы, вы можете предоставить Django SELECT , INSERT , UPDATE и
УДАЛИТЬ разрешений. После создания пользователя базы данных с этими разрешениями,
вы укажете детали в файле настроек вашего проекта, см.
БАЗЫ ДАННЫХ для подробностей.

Если вы используете среду тестирования Django для тестирования
запросы к базе данных, Django потребуется разрешение на создание тестовой базы данных.

Установите код Django¶

Инструкции по установке немного отличаются в зависимости от того,
установка пакета для конкретного дистрибутива, загрузка последней официальной версии
выпуск или получение последней разрабатываемой версии.

Установка официального релиза с

pip ¶

Это рекомендуемый способ установки Django.

1. Установить трубопровод. Самый простой — использовать автономный установщик pip. Если твой
   В дистрибутиве уже установлено pip , вам может потребоваться обновить его, если
   это устарело. Если он устарел, вы узнаете, потому что установка не будет
   Работа.

2. Взгляните на venv. Этот инструмент предоставляет
   изолированные среды Python, которые более практичны, чем установка
   пакеты по всей системе. Он также позволяет устанавливать пакеты без
   права администратора. В дополнительном руководстве рассказывается, как создать виртуальную среду.

3. После создания и активации виртуальной среды введите команду:

Установка пакета для конкретного дистрибутива¶

Проверьте примечания к дистрибутиву,
ваша платформа / дистрибутив предоставляет официальные пакеты / установщики Django.
Пакеты, предоставляемые распространением, обычно допускают автоматическую установку
зависимостей и поддерживаемых путей обновления; однако эти пакеты редко
содержат последнюю версию Django.

Установка разрабатываемой версии¶

Отслеживание разработки Django

Если вы решите использовать последнюю разрабатываемую версию Django,
вам нужно внимательно следить за сроками разработки,
и вы захотите следить за примечаниями к выпуску для
предстоящий выпуск. Это поможет тебе остаться
помимо любых новых функций, которые вы, возможно, захотите использовать, а также любых изменений
вам нужно будет внести изменения в свой код при обновлении копии Django.
(Для стабильных выпусков все необходимые изменения документируются в
примечания к выпуску.)

Если вы хотите иметь возможность время от времени обновлять свой код Django с помощью
последние исправления ошибок и улучшения, следуйте этим инструкциям:

1. Убедитесь, что у вас установлен Git и вы можете запускать его команды
   из ракушки. (Введите git help в приглашении оболочки, чтобы проверить это.)

2. Проверьте основную ветку разработки Django, например:

   Это создаст каталог django в вашем текущем каталоге.

3. Убедитесь, что интерпретатор Python может загружать код Django. Большинство
   Удобный способ сделать это — использовать виртуальную среду и pip. В
   участвуя в учебном пособии, мы расскажем, как
   создать виртуальную среду.

4. После настройки и активации виртуальной среды запустите следующую
   команда:

   Это сделает код Django импортируемым, а также сделает
   django-admin Доступна команда утилиты . Другими словами, вы все
   установленный!

Если вы хотите обновить свою копию исходного кода Django, выполните команду
git pull из каталога django .Когда вы это сделаете, Git будет
скачать любые изменения.

django-admin и manage.py | Документация Django

django-admin — это утилита командной строки Django для административных задач.
Этот документ описывает все, что он может делать.

Кроме того, в каждом проекте Django автоматически создается manage.py . Это
делает то же самое, что и django-admin , но также устанавливает
DJANGO_SETTINGS_MODULE переменная среды, чтобы она указывала на ваш
настройки проекта .py файл.

Скрипт django-admin должен находиться в вашем системном пути, если вы установили
Django через pip . Если это не на вашем пути, убедитесь, что у вас есть виртуальный
среда активирована.

Как правило, при работе над одним проектом Django проще использовать
manage.py , чем django-admin . Если вам нужно переключиться между несколькими
Файлы настроек Django, используйте django-admin с
DJANGO_SETTINGS_MODULE или командная строка --settings
вариант.

В примерах командной строки в этом документе используется django-admin для
быть последовательным, но в любом примере можно использовать manage.py или python -m django
так же, как и.

Использование

команда должна быть одной из команд, перечисленных в этом документе.
опций , что является необязательным, должно быть ноль или более доступных опций
для данной команды.

Получение справки во время выполнения¶

django-admin help ¶

Запустите django-admin help , чтобы отобразить информацию об использовании и список
команды, предоставляемые каждым приложением.

Запустите django-admin help - команды , чтобы отобразить список всех доступных
команды.

Запустите django-admin help <команда> , чтобы отобразить описание данного
команда и список ее доступных опций.

Имена приложений¶

Многие команды принимают список «имен приложений». «Имя приложения» — это базовое имя
пакет, содержащий ваши модели. Например, если ваш INSTALLED_APPS
содержит строку 'mysite.blog' , имя приложения — blog .

Определение версии¶

django-admin версия ¶

Запустите django-admin version , чтобы отобразить текущую версию Django.

Вывод соответствует схеме, описанной в PEP 440 :

Отображение вывода отладки¶

Используйте --verbosity , если он поддерживается, чтобы указать количество
уведомление и отладочная информация, которую django-admin выводит на консоль.

Доступные команды¶

чек ¶

django-admin check [app_label [app_label ...]]

Использует структуру проверки системы для проверки всего
Проект Django для общих проблем.

По умолчанию проверяются все приложения. Вы можете проверить подмножество приложений,
предоставление списка ярлыков приложений в качестве аргументов:

 django-admin проверить auth admin myapp
 

- тег TAGS , -t TAGS ¶

Среда проверки системы выполняет множество различных типов проверок, которые
разделены на категории с помощью тегов.Вы можете использовать эти
теги, чтобы ограничить выполняемые проверки только теми, которые относятся к определенной категории.
Например, чтобы выполнить только проверки моделей и совместимость, запустите:

 django-admin check --tag models --tag compatibility
 

- база данных БАЗА ДАННЫХ ¶

Новое в Django 3.1.

Указывает базу данных для запуска проверок, требующих доступа к базе данных:

 django-admin check --database default --database other
 

По умолчанию эти проверки не запускаются.

--list-tags ¶

Выводит список всех доступных тегов.

- развернуть ¶

Активирует некоторые дополнительные проверки, относящиеся только к параметрам развертывания.

Вы можете использовать эту опцию в своей локальной среде разработки, но поскольку ваш
в модуле локальных настроек разработки может не быть многих из ваших производственных настроек,
вы, вероятно, захотите указать команде check другие настройки
модуль, либо установив среду DJANGO_SETTINGS_MODULE
переменной, или передав параметр --settings :

 django-admin check --deploy --settings = production_settings
 

Или вы можете запустить его непосредственно в производственном или промежуточном развертывании, чтобы проверить
что используются правильные настройки (исключая - настройки ).Ты мог бы даже
сделать его частью вашего набора интеграционных тестов.

- уровень сбоя {CRITICAL, ERROR, WARNING, INFO, DEBUG} ¶

Задает уровень сообщения, при котором команда завершается с ненулевым
положение дел. По умолчанию ОШИБКА .

собрать сообщения ¶

django-admin compilemessages ¶

Компилирует файлов .po , созданных makemessages с по .mo файлов для
использовать со встроенной поддержкой gettext. См. Интернационализация и локализация.

- местный МЕСТНЫЙ , -l МЕСТНЫЙ ¶

Задает языковые стандарты для обработки. Если не указан, обрабатываются все языковые стандарты.

- исключить ИСКЛЮЧИТЬ , -x ИСКЛЮЧИТЬ ¶

Задает языковой стандарт, который следует исключить из обработки.Если не указан, то язык не указан.
исключены.

- нечеткое использование , -f ¶

Включает нечеткие переводы в скомпилированные файлы.

Пример использования:

 django-admin compilemessages --locale = pt_BR
django-admin compilemessages --locale = pt_BR --locale = fr -f
django-admin compilemessages -l pt_BR
django-admin compilemessages -l pt_BR -l fr --use-fuzzy
django-admin compilemessages --exclude = pt_BR
django-admin compilemessages --exclude = pt_BR --exclude = fr
django-admin compilemessages -x pt_BR
django-admin compilemessages -x pt_BR -x fr
 

- игнорировать ОБРАЗЕЦ , -i ОБРАЗЕЦ ¶

Игнорирует каталоги, соответствующие заданному шаблону стиля glob .Использовать
несколько раз, чтобы игнорировать больше.

Пример использования:

 django-admin compilemessages --ignore = cache --ignore = outdated / * / locale
 

createcachetable ¶

django-admin createcachetable ¶

Создает таблицы кэша для использования с серверной частью кэша базы данных, используя
информацию из вашего файла настроек. См. Фреймворк кеширования Django для получения дополнительной информации.
Информация.

- база данных БАЗА ДАННЫХ ¶

Определяет базу данных, в которой будут созданы кэш-таблицы.По умолчанию
по умолчанию .

- сухой ¶

Печатает SQL, который будет запускаться без его фактического запуска, поэтому вы можете
настройте его или воспользуйтесь фреймворком миграции.

dbshell ¶

django-admin dbshell ¶

Запускает клиент командной строки для ядра базы данных, указанного в вашем
ДВИГАТЕЛЬ настройка, с параметрами подключения
указанный в вашем ПОЛЬЗОВАТЕЛЬ , ПАРОЛЬ и т. д., настройки.

• Для PostgreSQL запускается клиент командной строки psql .
• Для MySQL запускается клиент командной строки mysql .
• Для SQLite запускается клиент командной строки sqlite3 .
• Для Oracle это запускает клиент командной строки sqlplus .

Эта команда предполагает, что программы находятся на вашем PATH , поэтому вызов
имя программы ( psql , mysql , sqlite3 , sqlplus ) найдет
программа в нужном месте.Невозможно указать местоположение
программировать вручную.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных, в которой открывается оболочка. По умолчанию по умолчанию .

- АРГУМЕНТЫ ¶

Новое в Django 3.1.

Любые аргументы, следующие за разделителем –, будут переданы в базовый
клиент командной строки. Например, с PostgreSQL вы можете использовать psql
флаг команды -c для непосредственного выполнения необработанного запроса SQL:

В MySQL / MariaDB это можно сделать с помощью флага -e команды mysql :

Примечание

Имейте в виду, что не все параметры, установленные в части OPTIONS вашего
конфигурация базы данных в БАЗЫ ДАННЫХ передаются в
клиент командной строки, e.грамм. 'Уровень_изоляции' .

Дифф. Настройки ¶

django-admin diffsettings ¶

Отображает различия между текущим файлом настроек и файлом по умолчанию Django.
settings (или другой файл настроек, указанный в - по умолчанию ).

Настройки, которые не отображаются по умолчанию, сопровождаются "###" . Для
Например, настройки по умолчанию не определяют ROOT_URLCONF , поэтому
ROOT_URLCONF сопровождается "###" в выводе
diffsettings .

- все ¶

Отображает все настройки, даже если они имеют значение по умолчанию для Django. Такие настройки
начинаются с префикса "###" .

- по умолчанию МОДУЛЬ ¶

Модуль настроек для сравнения текущих настроек. Оставьте пустым, чтобы
сравните с настройками Django по умолчанию.

- выход {хеш, унифицированный} ¶

Задает выходной формат.Доступные значения: hash и unified .
hash — это режим по умолчанию, в котором отображаются выходные данные, описанные выше.
унифицированный отображает вывод, аналогичный diff -u . Настройки по умолчанию:
с префиксом минус, за которым следует измененный параметр с префиксом
знак плюс.

dumpdata ¶

django-admin dumpdata [app_label [.ModelName] [app_label [.ModelName] ...]] ¶

Выводит на стандартный вывод все данные в базе данных, связанные с указанным
Приложения).

Если имя приложения не указано, все установленные приложения будут сброшены.

Вывод dumpdata можно использовать как ввод для loaddata .

Обратите внимание, что dumpdata использует диспетчер по умолчанию в модели для выбора
записи для сброса. Если вы используете персонализированный менеджер как
диспетчер по умолчанию, и он фильтрует некоторые из доступных записей, а не все
объекты будут сброшены.

- все , -a ¶

Использует базовый менеджер Django, сбрасывая записи, которые в противном случае могли бы быть отфильтрованы
или изменен специальным менеджером.

--формат ФОРМАТ ¶

Задает формат сериализации вывода. По умолчанию JSON. Поддерживается
форматы перечислены в форматах сериализации.

--индент INDENT ¶

Задает количество пробелов отступа для использования в выводе. По умолчанию
Нет , который отображает все данные в одной строке.

- исключить ИСКЛЮЧИТЬ , -e ИСКЛЮЧИТЬ ¶

Предотвращает определенные приложения или модели (указанные в форме
app_label.ModelName ) от сброса. Если указать название модели, то
будет исключена только эта модель, а не все приложение. Вы можете
также смешайте названия приложений и названия моделей.

Если вы хотите исключить несколько приложений, передайте - исключите больше, чем
один раз:

 django-admin dumpdata --exclude = auth --exclude = contenttypes
 

- база данных БАЗА ДАННЫХ ¶

Определяет базу данных, из которой будут выгружены данные.По умолчанию по умолчанию .

- натуральный иностранный ¶

Использует метод модели natural_key () для сериализации любого внешнего ключа и
отношение «многие ко многим» с объектами типа, определяющего метод. Если
вы сбрасываете contrib.auth Разрешение объектов или
contrib.contenttypes ContentType объектов, вам, вероятно, следует использовать это
флаг. Увидеть естественные ключи
документацию для получения более подробной информации об этом и следующем вариантах.

- первичный натуральный ¶

Пропускает первичный ключ в сериализованных данных этого объекта, поскольку он может быть
вычисляется во время десериализации.

--pks ПЕРВИЧНЫЕ_КЛЮЧИ ¶

Выводит только объекты, указанные в списке первичных ключей, разделенных запятыми.
Это доступно только при сбросе одной модели. По умолчанию все записи
модель выводится.

- выход ВЫХОД , -o ВЫХОД ¶

Задает файл для записи сериализованных данных.По умолчанию данные поступают в
стандартный вывод.

Если этот параметр установлен и --verbosity больше 0 (по умолчанию),
индикатор выполнения отображается в терминале.

Крепления компрессионные¶

Новое в Django 3.2.

Выходной файл можно сжать одним из следующих форматов: bz2 , gz , lzma или
xz форматирует, заканчивая имя файла соответствующим расширением.
Например, чтобы вывести данные в виде сжатого файла JSON:

 django-admin dumpdata -o mydata.json.gz
 

заподлицо ¶

django-admin flush ¶

Удаляет все данные из базы данных и повторно выполняет любую пост-синхронизацию.
обработчики. Таблица, для которой были применены миграции, не очищается.

Если вы предпочитаете начать с пустой базы данных и повторно запустить все миграции, вы
следует удалить и воссоздать базу данных, а затем вместо этого запустить , перенести .

- нет входа , - нет входа ¶

Подавляет все запросы пользователя.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных для очистки. По умолчанию по умолчанию .

inspectdb ¶

django-admin inspectdb [таблица [таблица ...]] ¶

Анализирует таблицы базы данных в базе данных, на которую указывает
NAME устанавливает и выводит модуль модели Django (a models.py
файл) в стандартный вывод.

Вы можете выбрать, какие таблицы или представления проверять, передав их имена как
аргументы.Если аргументы не указаны, модели создаются для представлений, только если
используется опция --include-views . Модели для таблиц разделов
создается в PostgreSQL, если используется параметр --include-partitions .

Используйте это, если у вас есть устаревшая база данных, с которой вы хотите использовать Django.
Скрипт проверит базу данных и создаст модель для каждой таблицы в
Это.

Как и следовало ожидать, у созданных моделей будет атрибут для каждого поля.
в таблице.Обратите внимание, что inspectdb имеет несколько особых случаев в имени поля.
вывод:

• Если inspectdb не может сопоставить тип столбца с типом поля модели, он
используйте TextField и вставьте комментарий Python
'Этот тип поля является предположением.' рядом с полем в сгенерированном
модель. Распознаваемые поля могут зависеть от приложений, перечисленных в
УСТАНОВЛЕННЫЕ ПРИЛОЖЕНИЯ . Например, django.contrib.postgres добавляет
распознавание нескольких типов полей, специфичных для PostgreSQL.
• Если имя столбца базы данных является зарезервированным словом Python (например,
'pass' , 'class' or 'for' ), inspectdb добавит
'_field' к имени атрибута. Например, если в таблице есть столбец
'для' , сгенерированная модель будет иметь поле 'for_field' , с
атрибут db_column установлен на 'для' . inspectdb вставит
комментарий Python
'Поле переименовано, потому что это зарезервированное слово Python.' рядом с
поле.

Эта функция предназначена для быстрого доступа, а не для окончательного создания модели. После
вы запустите его, вы захотите самостоятельно просмотреть сгенерированные модели, чтобы сделать
настройки. В частности, вам нужно будет изменить порядок моделей, чтобы
модели, относящиеся к другим моделям, заказываются правильно.

Django не создает базы данных по умолчанию, когда
по умолчанию указывается в поле модели.
Точно так же значения по умолчанию для базы данных не переводятся в значения по умолчанию для полей модели или
обнаруживается любым способом inspectdb .

По умолчанию inspectdb создает неуправляемые модели. То есть управляемых = Ложь
в модели Meta класс сообщает Django не управлять созданием каждой таблицы,
модификация и удаление. Если вы хотите разрешить Django управлять
жизненного цикла таблицы, вам нужно будет изменить
управляемый вариант на True (или удалить
это потому, что True — его значение по умолчанию).

Примечания, относящиеся к базе данных¶

PostgreSQL¶

• Модели созданы для сторонних таблиц.
• Модели создаются для материализованных представлений, если
--include-views используется.
• Модели создаются для таблиц разделов, если
--include-partitions используется.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных для самоанализа. По умолчанию по умолчанию .

--включить-разделы ¶

Если этот параметр включен, модели также создаются для разделов.

Реализована поддержка только PostgreSQL.

- включить-просмотры ¶

Если этот параметр указан, модели также создаются для представлений базы данных.

loaddata ¶

django-admin loaddata fixture [fixture ...] ¶

Ищет и загружает содержимое названного прибора в базу данных.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных, в которую будут загружены данные.По умолчанию
по умолчанию .

- игнорируется не существует , -i ¶

Игнорирует поля и модели, которые могли быть удалены после того, как прибор был
изначально сгенерирован.

- приложение APP_LABEL ¶

Задает одно приложение, в котором нужно искать приборы, а не искать во всех приложениях.

--формат ФОРМАТ ¶

Задает формат сериализации (например,грамм.,
json или xml ) для фикстур, считываемых из stdin.

- исключить ИСКЛЮЧИТЬ , -e ИСКЛЮЧИТЬ ¶

Исключает загрузку светильников из данных приложений и / или моделей (в
форма app_label или app_label.ModelName ). Используйте опцию множественный
раз, чтобы исключить более одного приложения или модели.

Что такое «приспособление»? ¶

Устройство — это набор файлов, содержащих сериализованное содержимое
база данных.У каждого прибора есть уникальное имя, а файлы, содержащие
fixture может быть распределена по нескольким каталогам в нескольких приложениях.

Django будет искать приборы в трех местах:

1. В каталоге fixtures каждого установленного приложения
2. В любом каталоге, указанном в параметре FIXTURE_DIRS ,
3. По буквальному пути, указанному прибором

Django загрузит все фикстуры, которые он найдет в этих местах, которые соответствуют
предоставленные имена приспособлений.

Если названный прибор имеет расширение файла, только приборы этого типа
будет загружен. Например:

 django-admin loaddata mydata.json
 

будет загружать только фикстуры JSON с именем mydata . Расширение приспособления
должно соответствовать зарегистрированному имени
сериализатор (например, json или xml ).

Если вы опустите расширения, Django будет искать все доступные типы устройств.
для подходящего приспособления. Например:

 django-admin loaddata mydata
 

будет искать любой прибор любого типа под названием mydata .Если приспособление
каталог содержит mydata.json , этот прибор будет загружен
как приспособление JSON.

Названные приборы могут включать в себя компоненты каталога. Эти
каталоги будут включены в путь поиска. Например:

 django-admin loaddata foo / bar / mydata.json
 

будет искать /fixtures/foo/bar/mydata.json для каждого установленного
application, /foo/bar/mydata.json для каждого каталога в
FIXTURE_DIRS и буквальный путь foo / bar / mydata.json .

При обработке файлов фикстур данные сохраняются в базе данных как есть.
Определенная моделью save () методы не вызываются, и
любой pre_save или
post_save сигналов будут вызываться с
raw = True , поскольку экземпляр содержит только атрибуты, которые являются локальными для
модель. Например, вы можете отключить обработчики, которые обращаются к
связанные поля, которые не присутствуют во время загрузки прибора и в противном случае
вызвать исключение:

 из django.db.models.signals import post_save
из .models import MyModel

def my_handler (** kwargs):
    # отключаем обработчик во время загрузки фикстуры
    если kwargs ['raw']:
        возвращение
    ...

post_save.connect (my_handler, sender = MyModel)
 

Вы также можете написать декоратор для инкапсуляции этой логики:

 от functools import wraps

def disable_for_loaddata (signal_handler):
    "" "
    Декоратор, отключающий обработчики сигналов при загрузке данных прибора.
    "" "
    @wraps (обработчик сигнала)
    def оболочка (* args, ** kwargs):
        если kwargs ['raw']:
            возвращение
        signal_handler (* аргументы, ** kwargs)
    возвратная обертка

@disable_for_loaddata
def my_handler (** kwargs):
    ...
 

Просто имейте в виду, что эта логика будет отключать сигналы всякий раз, когда приборы
десериализован, а не только во время loaddata .

Обратите внимание, что порядок, в котором обрабатываются файлы фикстур, не определен. Тем не мение,
все данные прибора устанавливаются как одна транзакция, поэтому данные в
один прибор может ссылаться на данные другого прибора. Если серверная часть базы данных
поддерживает ограничения на уровне строк, эти ограничения будут проверяться на
конец транзакции.

Команда dumpdata может использоваться для генерации входных данных для loaddata .

Сжатые приспособления¶

Светильники могут быть сжаты в zip , gz , bz2 , lzma или xz
формат. Например:

 django-admin loaddata mydata.json
 

будет искать любой из mydata.json , mydata.json.zip , mydata.json.gz ,
mydata.json.bz2 , mydata.json.lzma или mydata.json.xz . Первое
файл, содержащийся в сжатом архиве.

Обратите внимание, что если два прибора с одинаковым названием, но разными
обнаруживается тип приспособления (например, если mydata.json и
mydata.xml.gz были найдены в том же каталоге фикстур), фикстур
установка будет прервана, и все данные, установленные при вызове
loaddata будет удален из базы данных.

MySQL с MyISAM и приспособлениями

Механизм хранения MyISAM MySQL не поддерживает транзакции или
ограничений, поэтому, если вы используете MyISAM, вы не получите подтверждение фикстуры
data или откат, если найдено несколько файлов транзакций.

Изменено в Django 3.2:

Добавлена ​​поддержка архивов XZ ( .xz ) и архивов LZMA ( .lzma ).

Приспособления для базы данных¶

Если вы работаете с несколькими базами данных, у вас могут быть данные фикстур, которые
вы хотите загрузить в одну базу данных, но не в другую. В этом
В этой ситуации вы можете добавить идентификатор базы данных в имена ваших приборов.

Например, если в настройках БАЗЫ ДАННЫХ есть «главная» база данных
определено, назовите прибор mydata.master.json или
mydata.master.json.gz и прибор будет загружен только тогда, когда вы
укажите, что вы хотите загрузить данные в базу данных master .

Загрузка приспособлений из

стандартного ¶

Вы можете использовать тире в качестве имени прибора для загрузки ввода из sys.stdin . Для
пример:

 django-admin loaddata --format = json -
 

При чтении из стандартного ввода опция --format
требуется для указания формата сериализации
входа (например,г., json или xml ).

Загрузка со стандартного ввода полезна со стандартными перенаправлениями ввода и вывода.
Например:

 django-admin dumpdata --format = json --database = test app_label.ModelName | django-admin loaddata --format = json --database = prod -
 

makemessages ¶

django-admin makemessages ¶

Обходит все дерево исходных текстов текущего каталога и извлекает все
строки, отмеченные для перевода.Он создает (или обновляет) файл сообщения в
conf / locale (в дереве Django) или locale (для проекта и приложения)
каталог. После внесения изменений в файлы сообщений их необходимо скомпилировать.
с compilemessages для использования со встроенной поддержкой gettext. Видеть
документацию i18n для подробностей.

Эта команда не требует дополнительных настроек. Однако, когда настройки не
настроен, команда не может игнорировать MEDIA_ROOT и
STATIC_ROOT каталогов или LOCALE_PATHS .

- все , -a ¶

Обновляет файлы сообщений для всех доступных языков.

- добавочный номер РАСШИРЕНИЯ , -e РАСШИРЕНИЯ ¶

Задает список расширений файлов для проверки (по умолчанию: html , txt ,
py или js , если --domain равен js ).

Пример использования:

 django-admin makemessages --locale = de --extension xhtml
 

Разделите несколько добавочных номеров запятыми или используйте -e или --extension
несколько раз:

 django-admin makemessages --locale = de --extension = html, txt --extension xml
 

- местный МЕСТНЫЙ , -l МЕСТНЫЙ ¶

Задает языковые стандарты для обработки.

- исключить ИСКЛЮЧИТЬ , -x ИСКЛЮЧИТЬ ¶

Задает языковой стандарт, который следует исключить из обработки.Если не указан, то язык не указан.
исключены.

Пример использования:

 django-admin makemessages --locale = pt_BR
django-admin makemessages --locale = pt_BR --locale = fr
django-admin makemessages -l pt_BR
django-admin makemessages -l pt_BR -l fr
django-admin makemessages --exclude = pt_BR
django-admin makemessages --exclude = pt_BR --exclude = fr
django-admin makemessages -x pt_BR
django-admin makemessages -x pt_BR -x fr
 

--домен ДОМЕН , -d ДОМЕН ¶

Задает домен файлов сообщений.Поддерживаемые варианты:

• django для всех файлов * .py , * .html и * .txt (по умолчанию)
• djangojs для файлов * .js

--симлинки , - s ¶

Следит за символическими ссылками на каталоги при поиске новых строк перевода.

Пример использования:

 django-admin makemessages --locale = de --symlinks
 

- игнорировать ОБРАЗЕЦ , -i ОБРАЗЕЦ ¶

Игнорирует файлы или каталоги, соответствующие заданному шаблону стиля glob .Использовать
несколько раз, чтобы игнорировать больше.

По умолчанию используются следующие шаблоны: 'CVS' , '. *' , '* ~' , '* .pyc' .

Пример использования:

 django-admin makemessages --locale = en_US --ignore = apps / * --ignore = secret / *. Html
 

--no-default-ignore ¶

Отключает значения по умолчанию - игнорировать .

- без упаковки ¶

Отключает разбиение длинных строк сообщения на несколько строк в языковых файлах.

- без местонахождения ¶

Подавляет запись строк комментариев ‘ #: filename: line ’ в языковых файлах.
Использование этой опции усложняет технически квалифицированным переводчикам
понимать контекст каждого сообщения.

--add-location [{full, file, never}] ¶

Управляет #: имя файла: строка строки комментариев в языковых файлах. Если вариант
это:

• полный (значение по умолчанию, если не указано): строки включают как имя файла, так и
номер строчки.
• файл : номер строки опущен.
• никогда : строки подавляются (то же, что и - no-location ).

Требуется gettext 0.19 или новее.

- горшок ¶

Предотвращает удаление временных файлов .pot , созданных перед созданием
.po файл. Это полезно для отладки ошибок, которые могут помешать окончательной
языковые файлы не создаются.

миграция ¶

django-admin makemigrations [app_label [app_label ...]]

Создает новые миграции на основе изменений, обнаруженных в ваших моделях.
Миграции, их связь с приложениями и многое другое подробно рассматривается в
документация по миграции.

Предоставление одного или нескольких имен приложений в качестве аргументов ограничит создаваемые миграции.
к указанным приложениям и любым необходимым зависимостям (таблица на другом конце
из ForeignKey , например).

Чтобы добавить миграции в приложение, в котором нет каталога migrations , запустите
makemigrations с приложением app_label .

- нет входа , - нет входа ¶

Подавляет все запросы пользователя. Если подавленное приглашение не может быть разрешено
автоматически, команда завершится с кодом ошибки 3.

- пусто ¶

Выводит пустую миграцию для указанных приложений для редактирования вручную.Это
для опытных пользователей и не должен использоваться, если вы не знакомы с
формат миграции, операции миграции и зависимости между вашими
миграции.

- сухой ¶

Показывает, какие миграции будут выполнены без фактического написания каких-либо миграций.
файлы на диск. Использование этой опции вместе с --verbosity 3 также покажет
полные файлы миграции, которые будут записаны.

- объединить ¶

Включает исправление конфликтов миграции.

- имя ИМЯ , -n ИМЯ ¶

Позволяет присвоить имя сгенерированной миграции (миграциям) вместо использования сгенерированного имени. В
имя должно быть действительным идентификатором Python.

- без заголовка ¶

Создание файлов миграции без версии Django и заголовка временной метки.

- чек ¶

Делает makemigrations завершает работу с ненулевым статусом, когда модель изменяется без
миграции обнаружены.

Изменено в Django 3.2:

Поддержка вызова makemigrations без активной базы данных.
подключение было добавлено. В этом случае проверьте последовательную миграцию.
история пропускается.

миграция ¶

django-admin migrate [app_label] [migration_name] ¶

Синхронизирует состояние базы данных с текущим набором моделей и миграций.
Миграции, их связь с приложениями и многое другое подробно рассматривается в
документация по миграции.

Поведение этой команды меняется в зависимости от предоставленных аргументов:

• Без аргументов: у всех приложений все миграции выполняются.
• : для указанного приложения запущены миграции, вплоть до
недавняя миграция. Это может потребовать выполнения миграции других приложений из-за
зависимостям.
• : переводит схему базы данных в состояние, в котором
именованная миграция применяется, но более поздние миграции в том же приложении не выполняются.
применяемый.Это может привести к неприменению миграции, если вы ранее
мигрировал после именованной миграции. Вы можете использовать префикс миграции
имя, например 0001 , если он уникален для данного имени приложения. Использовать
имя ноль для полной миграции назад, т.е. для отмены всех примененных
миграции для приложения.

Предупреждение

При неприменении миграций все зависимые миграции также будут
неприменено, независимо от . Вы можете использовать --plan для проверки
какие миграции не будут применяться.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных для миграции. По умолчанию по умолчанию .

- подделка ¶

Помечает миграции до целевой (согласно правилам выше) как
применяется, но без фактического запуска SQL для изменения схемы базы данных.

Это предназначено для опытных пользователей, чтобы управлять
текущее состояние миграции напрямую, если они вносят изменения вручную;
имейте в виду, что использование --fake может привести к переходу в состояние миграции
таблица в состояние, при котором для выполнения миграции потребуется ручное восстановление
работать правильно.

- фальшивый начальный ¶

Позволяет Django пропустить начальную миграцию приложения, если все таблицы базы данных с
названия всех моделей, созданных всеми
CreateModel операций в этом
миграция уже существует. Эта опция предназначена для использования при первом запуске
миграции против базы данных, которая ранее использовала миграции. Этот
опция, однако, не проверяет соответствие схемы базы данных за пределами соответствия
имена таблиц и поэтому безопасно использовать только в том случае, если вы уверены, что ваш существующий
схема соответствует тому, что записано в вашей первоначальной миграции.

--план ¶

Показывает операции миграции, которые будут выполнены для данного migrate
команда.

--run-syncdb ¶

Позволяет создавать таблицы для приложений без миграции. Пока это не
рекомендуется, фреймворк миграции иногда слишком медленный для больших проектов
с сотнями моделей.

- нет входа , - нет входа ¶

Подавляет все запросы пользователя.Пример подсказки спрашивает об удалении устаревшего
типы контента.

- чек ¶

Новое в Django 3.1.

Делает миграцию завершает с ненулевым статусом, когда непримененные миграции
обнаружен.

сервер запуска ¶

django-admin runserver [addrport] ¶

Запускает облегченный веб-сервер разработки на локальном компьютере. По умолчанию,
сервер работает на порту 8000 по IP-адресу 127.0.0.1 . Вы можете пройти в
Явный IP-адрес и номер порта.

Если вы запустите этот сценарий как пользователь с обычными привилегиями (рекомендуется), вы
может не иметь доступа для запуска порта с низким номером порта. Меньшие номера портов
зарезервированы для суперпользователя (root).

Этот сервер использует объект приложения WSGI, указанный в
Настройка WSGI_APPLICATION .

НЕ ИСПОЛЬЗУЙТЕ ДАННЫЙ СЕРВЕР В ПРОИЗВОДСТВЕННЫХ НАСТРОЙКАХ. Это не прошло
аудиты безопасности или тесты производительности.(И так оно и останется. Мы в
бизнес по созданию веб-фреймворков, а не веб-серверов, поэтому улучшение этого
сервер, чтобы иметь возможность обрабатывать производственную среду, выходит за рамки
Джанго.)

Сервер разработки автоматически перезагружает код Python для каждого запроса, как
нужный. Вам не нужно перезапускать сервер, чтобы изменения кода вступили в силу.
Однако некоторые действия, такие как добавление файлов, не вызывают перезапуск, поэтому вы
в этих случаях необходимо перезапустить сервер.

Если вы используете Linux или MacOS и устанавливаете pywatchman и
Служба сторожа, сигналы ядра будут использоваться для автоматической перезагрузки сервера
(вместо опроса временных меток изменения файла каждую секунду).Это предлагает
лучшая производительность на больших проектах, сокращение времени отклика после изменения кода,
более надежное обнаружение изменений и снижение энергопотребления. Django поддерживает
pywatchman 1.2.0 и выше.

Большие каталоги с большим количеством файлов могут вызвать проблемы с производительностью

При использовании Watchman с проектом, который включает большие файлы, отличные от Python.
такие каталоги, как node_modules , рекомендуется игнорировать этот каталог
для оптимальной производительности. См. Информацию в документации сторожа.
о том, как это сделать.

Тайм-аут сторожа

DJANGO_WATCHMAN_TIMEOUT ¶

По умолчанию время ожидания клиента Watchman составляет 5 секунд. Вы можете это изменить
установив переменную среды DJANGO_WATCHMAN_TIMEOUT .

Когда вы запускаете сервер, и каждый раз, когда вы меняете код Python, пока
сервер запущен, фреймворк проверки системы проверит весь ваш Django
на наличие распространенных ошибок в проекте (см. команду check ).Если есть
обнаружены ошибки, они будут выведены на стандартный вывод.

Вы можете запускать столько одновременных серверов, сколько хотите, пока они
разделите порты, выполнив django-admin runserver более одного раза.

Обратите внимание, что IP-адрес по умолчанию, 127.0.0.1 , недоступен из других
машины в вашей сети. Чтобы сделать ваш сервер разработки доступным для просмотра другим
машины в сети, используйте собственный IP-адрес (например, 192.168.2.1 ) или
0.0.0.0 или :: (с включенным IPv6).

Вы можете указать IPv6-адрес в скобках.
(например, [200a :: 1]: 8000 ). Это автоматически включит поддержку IPv6.

Также можно использовать имя хоста, содержащее символы только ASCII.

Если включено приложение staticfiles contrib
(по умолчанию в новых проектах) команда runserver будет отменена
с собственной командой runserver.

Регистрация каждого запроса и ответа сервера отправляется на
джанго.регистратор сервера.

- дозаправка ¶

Отключает автоперезагрузку. Это означает, что любые изменения кода Python, которые вы вносите, пока
сервер работает, , а не , вступит в силу, если определенные модули Python
уже загружены в память.

--нерезьба ¶

Отключает использование потоковой передачи на сервере разработки. Сервер
по умолчанию многопоточный.

--ipv6 , -6 ¶

Использует IPv6 для сервера разработки.Это изменяет IP-адрес по умолчанию с
127.0.0.1 до :: 1 .

Примеры использования разных портов и адресов¶

Порт 8000 на IP-адресе 127.0.0.1 :

Порт 8000 на IP-адресе 1.2.3.4 :

 сервер запуска django-admin 1.2.3.4:8000
 

Порт 7000 на IP-адресе 127.0.0.1 :

 сервер запуска django-admin 7000
 

Порт 7000 на IP-адресе 1.2.3.4 :

 django-admin runserver 1.2.3.4: 7000
 

Порт 8000 на IPv6-адресе :: 1 :

 django-admin сервер запуска -6
 

Порт 7000 на IPv6-адресе :: 1 :

 django-admin сервер запуска -6 7000
 

Порт 7000 на IPv6-адресе 2001: 0db8: 1234: 5678 :: 9 :

 django-admin runserver [2001: 0db8: 1234: 5678 :: 9]: 7000
 

Порт 8000 на IPv4-адресе хоста localhost :

 django-admin сервер запуска локальный: 8000
 

Порт 8000 на IPv6-адресе хоста localhost :

 django-admin сервер запуска -6 локальный: 8000
 

посл. Письмо ¶

django-admin sendtestemail [электронная почта [электронная почта...]] ¶

Отправляет тестовое электронное письмо (чтобы подтвердить, что отправка электронной почты через Django работает) на
получатель (и) указан. Например:

 django-admin sendtestemail [email protected] [email protected]
 

Есть несколько вариантов, и вы можете использовать любую их комбинацию.
вместе:

- менеджеры ¶

Отправляет по электронной почте адреса, указанные в MANAGERS , используя
mail_managers () .

- администраторы ¶

Отправляет по электронной почте адреса, указанные в ADMINS , используя
mail_admins () .

оболочка ¶

оболочка django-admin ¶

Запускает интерактивный интерпретатор Python.

- интерфейс {ipython, bpython, python} , -i {ipython, bpython, python} ¶

Задает используемую оболочку.По умолчанию Django будет использовать IPython или bpython, если
либо установлено. Если оба установлены, укажите, какой из них вы хотите вот так:

IPython:

 оболочка django-admin -i ipython
 

байтон:

 оболочка django-admin -i bpython
 

Если у вас установлена ​​«богатая» оболочка, но вы хотите принудительно использовать «обычную»
Интерпретатор Python, используйте python в качестве имени интерфейса, например:

 оболочка django-admin -i python
 

- без запуска ¶

Отключает чтение сценария запуска для «простого» интерпретатора Python.К
по умолчанию сценарий, на который указывает среда PYTHONSTARTUP
переменная или сценарий ~ / .pythonrc.py читается.

- команда КОМАНДА , -c КОМАНДА ¶

Позволяет передать команду в виде строки, чтобы выполнить ее как Django, например:

 django-admin shell --command = "import django; print (django .__ version__)"
 

Вы также можете передать код на стандартный ввод для его выполнения.Например:

 $ django-admin shell << EOF
> импортировать django
> печать (django .__ version__)
> EOF
 

В Windows REPL выводится из-за ограничений реализации
select.select () на этой платформе.

показов ¶

django-admin showmigrations [app_label [app_label ...]]

Показывает все миграции в проекте. Вы можете выбрать один из двух форматов:

--список , -l ¶

Список всех приложений, о которых знает Django, миграции, доступные для каждого
приложение, и применяется ли каждая миграция (отмечена значком [X] рядом с
название миграции).Для --verbosity от 2 и выше применяется
Также показаны даты и время.

Приложения без миграций также перечислены, но имеют (без миграций) напечатано
под ними.

Это выходной формат по умолчанию.

--план , -p ¶

Показывает план миграции, которого Django будет придерживаться, чтобы применить миграции. Нравиться
- список , примененные миграции отмечены [X] .Для - многословие
2 и более поздних версий также будут показаны все зависимости миграции.

app_label аргументы ограничивают вывод, однако зависимости предоставленных
приложения также могут быть включены.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных для проверки. По умолчанию по умолчанию .

sqlflush ¶

django-admin sqlflush

Печатает операторы SQL, которые будут выполняться для сброса
команда.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных, для которой нужно распечатать SQL. По умолчанию по умолчанию .

sqlmigrate ¶

django-admin sqlmigrate app_label migration_name ¶

Печатает SQL для именованной миграции. Для этого требуется активная база данных
соединение, которое он будет использовать для разрешения имен ограничений; это означает, что вы должны
сгенерируйте SQL для копии базы данных, которую вы хотите позже применить.

Обратите внимание, что sqlmigrate не окрашивает свой вывод.

- назад ¶

Создает SQL для отмены миграции. По умолчанию созданный SQL
для выполнения миграции в прямом направлении.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных, для которой создается SQL. По умолчанию по умолчанию .

sqlsequencereset ¶

django-admin sqlsequencereset app_label [app_label...] ¶

Печатает операторы SQL для сброса последовательностей для заданных имен приложений.

Последовательности — это индексы, используемые некоторыми механизмами баз данных для отслеживания следующих доступных
номер для автоматически увеличиваемых полей.

Используйте эту команду для генерации SQL, который исправит случаи, когда последовательность отсутствует.
синхронизации с автоматически увеличиваемыми данными поля.

- база данных БАЗА ДАННЫХ ¶

Задает базу данных, для которой нужно распечатать SQL.По умолчанию по умолчанию .

сквошмиграции ¶

django-admin squashmigrations app_label [start_migration_name] migration_name ¶

Сворачивает миграции для app_label до включительно, migration_name
по возможности сократить количество миграций. В результате раздавленные миграции
могут спокойно жить рядом с непрессованными. Для дополнительной информации,
прочтите, пожалуйста, «Сжатие миграций».

Если задано start_migration_name , Django будет включать только миграции.
начиная с этой миграции и включительно. Это помогает уменьшить
ограничение сжатия RunPython и
django.db.migrations.operations.RunSQL операции миграции.

- не оптимизировать ¶

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

- нет входа , - нет входа ¶

Подавляет все запросы пользователя.

--squashed-name SQUASHED_NAME ¶

Задает имя сжатой миграции. Если не указано, имя основано на
первая и последняя миграция с _squashed_ между ними.

- без заголовка ¶

Сгенерировать сжатый файл миграции без версии Django и заголовка временной метки.

startapp ¶

django-admin startapp name [каталог] ¶

Создает структуру каталогов приложения Django для данного имени приложения в текущем
каталог или указанный пункт назначения.

По умолчанию новый каталог содержит
models.py и другие файлы шаблонов приложений.Если указано только название приложения,
каталог приложения будет создан в текущем рабочем каталоге.

Если указан необязательный пункт назначения, Django будет использовать существующий
каталог, а не создавать новый. Вы можете использовать «.» Для обозначения текущего
рабочий каталог.

Например:

 django-admin startapp myapp / Пользователи / jezdez / Код / myapp
 

--шаблон ШАБЛОН ¶

Предоставляет путь к каталогу с файлом настраиваемого шаблона приложения или путь к
несжатый архив (.tar ) или сжатый архив ( .tar.gz ,
.tar.bz2 , .tar.xz , .tar.lzma , .tgz , .tbz2 , .txz ,
.tlz , .zip ), содержащий файлы шаблонов приложения.

Например, это будет искать шаблон приложения в данном каталоге, когда
создание приложения myapp :

 django-admin startapp --template = / Пользователи / jezdez / Код / my_app_template myapp
 

Django также принимает URL-адреса ( http , https , ftp ) для сжатых файлов.
архивы с файлами шаблонов приложений, скачивая и распаковывая их на
летать.

Например, используя функцию GitHub для отображения репозиториев как
zip-файлы, вы можете использовать URL-адрес, например:

 django-admin startapp --template = https: //github.com/githubuser/django-app-template/archive/master.zip myapp
 

- добавочный номер РАСШИРЕНИЯ , -e РАСШИРЕНИЯ ¶

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

- имя ФАЙЛОВ , -n ФАЙЛОВ ¶

Указывает, какие файлы в шаблоне приложения (помимо тех, которые соответствуют
--extension ) должен отображаться с помощью механизма шаблонов. По умолчанию
пустой список.

Контекст шаблона , используемый для всех сопоставлений
файлов:

• Любой параметр, переданный команде startapp (среди поддерживаемых
варианты)
• app_name — имя приложения, переданное команде
• app_directory — полный путь к вновь созданному приложению
• camel_case_app_name — имя приложения в формате camel case
• docs_version — версия документации: 'dev' или '1.x '
• django_version — версия Django, например '2.0.3'

Предупреждение

Когда файлы шаблона приложения визуализируются с помощью шаблона Django
движок (по умолчанию все файлы * .py ), Django также заменит все
содержались случайные переменные шаблона. Например, если один из файлов Python
содержит строку документации, объясняющую конкретную функцию, связанную с
для рендеринга шаблона, это может привести к неверному примеру.

Чтобы обойти эту проблему, вы можете использовать тег шаблона
тег шаблона, чтобы «избежать» различных частей синтаксиса шаблона.

Кроме того, чтобы разрешить файлы шаблонов Python, содержащие шаблон Django
синтаксис языка, а также предотвращает попытки упаковочных систем
байтовая компиляция неверных файлов * .py , файлы шаблонов заканчиваются на .py-tpl
будет переименован в .py .

startproject ¶

django-admin startproject name [каталог] ¶

Создает структуру каталогов проекта Django для данного имени проекта в
текущий каталог или указанное место назначения.

По умолчанию новый каталог содержит
manage.py и пакет проекта (содержащий settings.py и другие
файлы).

Если указано только имя проекта, и каталог проекта, и проект
пакет будет называться и каталог проекта
будет создан в текущем рабочем каталоге.

Если указан необязательный пункт назначения, Django будет использовать существующий
каталог в качестве каталога проекта и создайте manage.py и проект
пакет внутри него. Используйте «.» Для обозначения текущего рабочего каталога.

Например:

 django-admin startproject myproject / Пользователи / jezdez / Код / myproject_repo
 

--шаблон ШАБЛОН ¶

Задает каталог, путь к файлу или URL-адрес настраиваемого шаблона проекта. Увидеть
startapp --template документация для примеров и использования.

- добавочный номер РАСШИРЕНИЯ , -e РАСШИРЕНИЯ ¶

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

- имя ФАЙЛОВ , -n ФАЙЛОВ ¶

Указывает, какие файлы в шаблоне проекта (в дополнение к тем, которые соответствуют
--extension ) должен отображаться с помощью механизма шаблонов. По умолчанию
пустой список.

Используемый контекст шаблона :

• Любая опция, переданная команде startproject (среди
поддерживаемые опции)
• имя_проекта — имя проекта, переданное команде
• project_directory — полный путь к вновь созданному проекту
• secret_key — случайный ключ для SECRET_KEY , установка
• docs_version — версия документации: 'dev' или '1.x '
• django_version — версия Django, например '2.0.3'

См. Также упомянутое предупреждение о рендеринге.
для startapp .

тест ¶

django-admin test [test_label [test_label ...]]

Выполняет тесты для всех установленных приложений. Подробнее см. Тестирование в Django.
Информация.

- с доставкой ¶

Останавливает выполнение тестов и сообщает о сбое сразу после сбоя теста.

--testrunner TESTRUNNER ¶

Управляет классом средства выполнения тестов, который используется для выполнения тестов. Это значение
отменяет значение, предоставленное настройкой TEST_RUNNER .

- нет входа , - нет входа ¶

Подавляет все запросы пользователя. Типичное приглашение — это предупреждение об удалении
существующая тестовая база данных.

Опции тестового бегуна¶

Команда test получает параметры от имени указанного
- testrunner .Это параметры средства запуска тестов по умолчанию:
DiscoverRunner .

--keepdb ¶

Сохраняет тестовую базу данных между тестовыми запусками. Это имеет преимущество
пропуская действия по созданию и уничтожению, что может значительно уменьшить
время запускать тесты, особенно в большом наборе тестов. Если тестовая база данных
не существует, он будет создан при первом запуске, а затем сохранен для каждого
последующий запуск. Если только настройка теста MIGRATE не
False , любые непримененные миграции также будут применены к тестовой базе данных.
перед запуском набора тестов.

- реверс , -r ¶

Сортировка тестовых примеров в обратном порядке выполнения. Это может помочь в отладке
побочные эффекты тестов, которые не изолированы должным образом. Группировка по тесту
класс сохраняется при использовании этой опции.

- режим отладки ¶

Устанавливает для параметра DEBUG значение True перед запуском тестов. Это может
помогите устранить неполадки при тестировании.

--debug-sql , -d ¶

Включает ведение журнала SQL для неудачных тестов. Если
--verbosity равно 2 , то также выводятся запросы при прохождении тестов.

- параллельный [N] ¶

DJANGO_TEST_PROCESSES

Выполняет тесты в отдельных параллельных процессах. Поскольку современные процессоры имеют
несколько ядер, это позволяет запускать тесты значительно быстрее.

По умолчанию --parallel запускает один процесс на ядро ​​в соответствии с
multiprocessing.cpu_count () . Вы можете настроить количество процессов
либо указав его в качестве значения опциона, например --parallel = 4 , или
установка переменной среды DJANGO_TEST_PROCESSES .

Django распространяет тестовые примеры — unittest.TestCase подклассы — для
подпроцессы. Если тестовых примеров меньше, чем настроенных процессов, Django
соответственно уменьшит количество процессов.

Каждый процесс получает свою базу данных. Вы должны убедиться, что разные тестовые примеры
не имеют доступа к тем же ресурсам. Например, тестовые случаи, которые касаются
файловая система должна создать временный каталог для собственного использования.

Для этого параметра требуется сторонний пакет tblib для отображения трассировки.
правильно:

 $ python -m pip install tblib
 

Эта функция недоступна в Windows. Не работает с Oracle
база данных тоже.

Если вы хотите использовать pdb при отладке тестов, вы должны отключить параллельный
исполнение ( --parallel = 1 ). Вы увидите что-то вроде bdb.BdbQuit , если вы
не надо.

Предупреждение

Когда тестовое распараллеливание включено и тест не проходит, Django может быть
невозможно отобразить трассировку исключения. Это может сделать отладку
сложно. Если вы столкнулись с этой проблемой, запустите соответствующий тест без
распараллеливание, чтобы увидеть обратную связь с ошибкой.

Это известное ограничение. Возникает из-за необходимости сериализации объектов
чтобы обмениваться ими между процессами. Видеть
Что можно мариновать и не мариновать? для подробностей.

- тег ТЕГИ ¶

Выполняет только тесты, отмеченные указанными тегами.
Можно указывать несколько раз и комбинировать с test --exclude-tag .

- тег исключения EXCLUDE_TAGS ¶

Исключает тесты, отмеченные указанными тегами.Можно указывать несколько раз и комбинировать с тестом - тег .

-k ИМЯ_ЗАПИСИ ИМЕНА ¶

Запускает методы и классы тестов, соответствующие шаблонам имен тестов, так же, как
опция unittest -k . Можно указывать несколько раз.

Python 3.7 и выше

Эта функция доступна только для Python 3.7 и новее.

--pdb ¶

Создает отладчик pdb при каждой ошибке или сбое теста.Если у тебя это есть
установлен, вместо него используется ipdb .

--буфер , -b ¶

Новое в Django 3.1.

Отклоняет вывод ( stdout и stderr ) для прохождения тестов таким же образом
как параметр unittest --buffer .

- безаварийный погрузчик ¶

Новое в Django 3.2.

Django автоматически вызывает обработчик ошибок .enable () при запуске
tests, что позволяет ему распечатать трассировку в случае сбоя интерпретатора. Проходить
--no-faulthandler , чтобы отключить это поведение.

- синхронизация ¶

Новое в Django 3.2.

Выводит время, включая настройку базы данных и общее время работы.

тестовый сервер ¶

django-admin testserver [приспособление [приспособление ...]]

Запускает сервер разработки Django (как в runserver ) с использованием данных из
данное приспособление (а).

Например, эта команда:

 тестовый сервер django-admin mydata.json
 

… выполнит следующие шаги:

1. Создайте тестовую базу данных, как описано в разделе «Тестовая база данных».
2. Заполнить тестовую базу данных данными приборов из заданных приборов.
(Подробнее о приспособлениях см. Выше в документации для loaddata .)
3. Запускает сервер разработки Django (как в runserver ), указанный на
эта недавно созданная тестовая база данных вместо вашей производственной базы данных.

Это полезно по-разному:

• Когда вы пишете модульные тесты того, как ваши представления
работать с определенными данными прибора, вы можете использовать testserver для взаимодействия с
представления в веб-браузере вручную.
• Допустим, вы разрабатываете свое приложение Django и у вас «нетронутый»
копия базы данных, с которой вы хотите взаимодействовать. Вы можете сбросить свой
базу данных в прибор (с помощью команды dumpdata , объяснено
выше), затем используйте testserver для запуска вашего веб-приложения с этими данными.Благодаря такому расположению у вас есть возможность испортить свои данные.
в любом случае, зная, что любые изменения данных, которые вы вносите,
вносится в тестовую базу данных.

Обратите внимание, что этот сервер , а не , автоматически обнаруживает изменения в вашем Python
исходный код (как это делает runserver ). Однако он обнаруживает изменения в
шаблоны.

--addrport ADDRPORT ¶

Задает порт или IP-адрес и порт, отличный от значения по умолчанию.
127.0.0.1: 8000 . Это значение соответствует точно такому же формату и служит
точно такая же функция, как аргумент команды runserver .

Примеры:

Для запуска тестового сервера на порту 7000 с fixture1 и fixture2 :

 django-admin testserver --addrport 7000 fixture1 fixture2
django-admin testserver fixture1 fixture2 --addrport 7000
 

(Приведенные выше утверждения эквивалентны. Мы включаем их оба, чтобы продемонстрировать
что не имеет значения, идут ли варианты до или после приспособления
аргументы.)

Для работы на 1.2.3.4:7000 с тестом прибор:

 django-admin testserver --addrport 1.2.3.4:7000 test
 

- нет входа , - нет входа ¶

Подавляет все запросы пользователя. Типичное приглашение — это предупреждение об удалении
существующая тестовая база данных.

Безопасность

в Django | Документация Django

Этот документ представляет собой обзор функций безопасности Django.Включает совет
по обеспечению безопасности сайта на Django.

Защита от межсайтового скриптинга (XSS)

XSS-атаки позволяют пользователю внедрять клиентские скрипты в браузеры
другие пользователи. Обычно это достигается путем хранения вредоносных скриптов в
база данных, из которой она будет извлечена и показана другим пользователям, или путем получения
пользователи должны щелкнуть ссылку, которая вызовет выполнение JavaScript злоумышленника
браузером пользователя. Однако XSS-атаки могут исходить от любого ненадежного
источник данных, такой как файлы cookie или веб-службы, когда данные не
достаточно продезинфицировать перед включением на страницу.

Использование шаблонов Django защищает вас от большинства XSS-атак.
Однако важно понимать, какую защиту он обеспечивает.
и его ограничения.

шаблонов Django экранирует определенные символы
которые особенно опасны для HTML. Хотя это защищает пользователей от большинства
злонамеренный ввод, это не совсем надежно. Например, не будет
защитить следующее:

Если для var установлено значение 'class1 onmouseover = javascript: func ()' , это может привести к
при несанкционированном выполнении JavaScript, в зависимости от того, как браузер отображает
несовершенный HTML.(Указание значения атрибута исправит этот случай.)

Также важно соблюдать особую осторожность при использовании is_safe с
настраиваемые теги шаблонов, тег шаблона safe , mark_safe , и когда автоэскейп отключен.

Кроме того, если вы используете систему шаблонов для вывода чего-то другого
чем HTML, могут быть совершенно отдельные символы и слова, которые требуют
побег.

Вы также должны быть очень осторожны при хранении HTML в базе данных, особенно
когда этот HTML извлекается и отображается.

Защита от подделки межсайтовых запросов (CSRF)

CSRF-атаки позволяют злоумышленнику выполнять действия с использованием учетных данных
другого пользователя без ведома или согласия этого пользователя.

Django имеет встроенную защиту от большинства типов CSRF-атак, предоставляя вам
включили и использовали его там, где это необходимо. Однако, как и в случае с
любой метод смягчения последствий есть ограничения. Например, можно
отключить модуль CSRF глобально или для определенных представлений.Вы должны делать только
это, если вы знаете, что делаете. Существуют и другие ограничения, если на вашем сайте есть субдомены за пределами вашего
контроль.

CSRF-защита работает, проверяя секрет в каждом
POST запрос. Это гарантирует, что злоумышленник не сможет «воспроизвести» POST-форму для
ваш веб-сайт, и другой зарегистрированный пользователь невольно отправит эту форму. В
злонамеренный пользователь должен знать секрет, зависящий от пользователя (используя
cookie).

При развертывании с HTTPS,
CsrfViewMiddleware проверит, что заголовок HTTP-реферера установлен на
URL-адрес того же источника (включая поддомен и порт).Потому что HTTPS
обеспечивает дополнительную безопасность, обязательно убедитесь, что соединения используют HTTPS
где он доступен, путем пересылки небезопасных запросов на соединение и использования
HSTS для поддерживаемых браузеров.

Будьте очень осторожны с маркировкой видов с помощью декоратора csrf_exempt , если только
это абсолютно необходимо.

Защита от SQL-инъекций¶

SQL-инъекция — это тип атаки, при которой злоумышленник может выполнить
произвольный код SQL в базе данных. Это может привести к записи
удаление или утечка данных.

Наборы запросов

Django защищены от SQL-инъекций, поскольку их запросы
построенный с использованием параметризации запроса. Код SQL запроса определен
отдельно от параметров запроса. Поскольку параметры могут быть предоставлены пользователем
и поэтому небезопасны, они экранируются базовым драйвером базы данных.

Django также дает разработчикам возможность писать необработанные запросы или выполнять собственный sql.
Эти возможности следует использовать с осторожностью, и вы всегда должны быть осторожны, чтобы
правильно экранировать любые параметры, которыми может управлять пользователь.Кроме того, вы
следует проявлять осторожность при использовании extra ()
и RawSQL .

Защита от кликджекинга¶

Clickjacking — это тип атаки, при которой вредоносный сайт обертывает другой сайт.
в кадре. Эта атака может привести к обману ничего не подозревающего пользователя.
на выполнение непредвиденных действий на целевом сайте.

Django содержит защиту от кликджекинга в
форма
Промежуточное ПО X-Frame-Options
который в поддерживающем браузере может предотвратить отображение сайта внутри
рамка.Можно отключить защиту для каждого просмотра
или настроить точное значение отправляемого заголовка.

Промежуточное ПО настоятельно рекомендуется для любого сайта, для которого не требуется
его страницы заключены во фрейм сторонними сайтами, или нужно только разрешить это
для небольшого раздела сайта.

SSL / HTTPS¶

Для безопасности всегда лучше развернуть ваш сайт по протоколу HTTPS. Без
это позволяет злоумышленникам сети прослушивать аутентификацию
учетные данные или любая другая информация, передаваемая между клиентом и сервером, и
в некоторых случаях — активных злоумышленников — для изменения данных, отправляемых в
в любом направлении.

Если вам нужна защита, обеспечиваемая HTTPS, и вы включили ее на своем
сервера, вам могут потребоваться дополнительные шаги:

• При необходимости установите SECURE_PROXY_SSL_HEADER , убедившись, что у вас есть
внимательно разобрался с предупреждениями. Несоблюдение этого может привести
в CSRF-уязвимостях, и неспособность сделать это правильно также может быть
опасный!

• Установите SECURE_SSL_REDIRECT на True , чтобы запросы по HTTP
перенаправляются на HTTPS.

  Обратите внимание на предостережения в SECURE_PROXY_SSL_HEADER . Для
в случае обратного прокси-сервера может быть проще или безопаснее настроить
основной веб-сервер для перенаправления на HTTPS.

• Используйте «безопасные» файлы cookie.

  Если браузер изначально подключается через HTTP, который используется по умолчанию для большинства
браузеры, возможна утечка существующих файлов cookie. По этой причине,
вы должны установить SESSION_COOKIE_SECURE и
CSRF_COOKIE_SECURE настройки на True .Это указывает браузеру
чтобы отправлять эти файлы cookie только через HTTPS-соединения. Обратите внимание, что это будет означать
что сеансы не будут работать через HTTP, а защита CSRF предотвратит
любые данные POST, принимаемые через HTTP (что будет нормально, если вы
перенаправление всего HTTP-трафика на HTTPS).

• Использовать строгую транспортную безопасность HTTP (HSTS)

  HSTS — это HTTP-заголовок, который сообщает браузеру, что все будущие подключения
к определенному сайту всегда следует использовать HTTPS. В сочетании с перенаправлением
запросы через HTTP на HTTPS, это гарантирует, что соединения всегда будут пользоваться
дополнительная безопасность SSL при условии, что произошло одно успешное соединение.HSTS может быть сконфигурирован с SECURE_HSTS_SECONDS ,
SECURE_HSTS_INCLUDE_SUBDOMAINS и SECURE_HSTS_PRELOAD ,
или на веб-сервере.

Проверка заголовка хоста¶

Django использует заголовок Host , предоставленный клиентом, для создания URL-адресов в
определенные случаи. Хотя эти значения дезинфицируются для предотвращения межсайтового скриптинга
атаки, поддельное значение Host может использоваться для подделки межсайтовых запросов,
атаки отравления кеша и отравления ссылок в электронных письмах.

Потому что даже кажущиеся безопасными конфигурации веб-сервера подвержены подделке.
Заголовки Host , Django проверяет заголовки Host на соответствие
ALLOWED_HOSTS Настройка в
django.http.HttpRequest.get_host () метод.

Эта проверка применяется только через get_host () ;
если ваш код обращается к заголовку Host непосредственно из запроса .META вы
обходят эту защиту.

Для получения дополнительных сведений см. Полную документацию ALLOWED_HOSTS .

Предупреждение

Предыдущие версии этого документа рекомендовали настроить веб-сервер для
убедитесь, что он проверяет входящие заголовки HTTP Host . Пока это еще
рекомендуется, на многих распространенных веб-серверах конфигурация, которая кажется
проверка заголовка Host на самом деле может этого не делать. Например, даже если
Apache настроен таким образом, что ваш сайт Django обслуживается не по умолчанию
виртуальный хост с установленным ServerName , это все еще возможно для HTTP
запрос на сопоставление этого виртуального хоста и предоставление поддельного заголовка Host .Таким образом,
Django теперь требует, чтобы вы явно указали ALLOWED_HOSTS .
чем полагаться на конфигурацию веб-сервера.

Кроме того, Django требует, чтобы вы явно включили поддержку
X-Forwarded-Host заголовок (через настройку USE_X_FORWARDED_HOST )
если этого требует ваша конфигурация.

Политика реферера¶

Браузеры используют заголовок Referer как способ отправки информации на сайт.
о том, как туда попали пользователи. Установив политику реферера , вы можете помочь
защищать конфиденциальность ваших пользователей, ограничивая при каких обстоятельствах
Заголовок Referer установлен.См. Раздел политики реферера в
справочник по промежуточному программному обеспечению безопасности для получения подробной информации.

Контент, загружаемый пользователями¶

• Если ваш сайт поддерживает загрузку файлов, настоятельно рекомендуется ограничить
эти загрузки в конфигурацию вашего веб-сервера в разумные
размер для предотвращения атак типа «отказ в обслуживании» (DOS). В Apache это
можно легко установить с помощью директивы LimitRequestBody.

• Если вы обслуживаете свои собственные статические файлы, убедитесь, что такие обработчики, как Apache
mod_php , который будет выполнять статические файлы как код, отключен.Ты не
хотят, чтобы пользователи могли выполнять произвольный код, загружая и запрашивая
специально созданный файл.

• Обработка загрузки мультимедиа в Django создает некоторые уязвимости, когда этот носитель
обслуживается способами, не соответствующими рекомендациям по обеспечению безопасности. В частности,
HTML-файл можно загрузить как изображение, если этот файл содержит допустимый PNG.
заголовок, за которым следует вредоносный HTML. Этот файл пройдет проверку на
библиотека, которую Django использует для изображения ImageField
обработка (Подушка).Когда этот файл впоследствии отображается в
пользователя, он может отображаться как HTML в зависимости от типа и конфигурации
ваш веб-сервер.

  На уровне структуры не существует пуленепробиваемого технического решения для безопасного
проверить все загруженное пользователем содержимое файла, однако есть и другие шаги
вы можете предпринять для смягчения этих атак:

  1. Один класс атак можно предотвратить, постоянно обслуживая загруженных пользователем
контент из отдельного домена верхнего или второго уровня. Это предотвращает
любой эксплойт, заблокированный политикой защиты одного происхождения, такой как перекрестный
скриптинг сайта.Например, если ваш сайт работает на example.com , вы
хотели бы обслуживать загруженный контент (параметр MEDIA_URL )
из чего-то вроде usercontent-example.com . недостаточно, чтобы
обслуживать контент из субдомена, например usercontent.example.com .
  2. Помимо этого, приложения могут определять список допустимых
расширения файлов для загруженных пользователем файлов и настройки веб-сервера
только для обслуживания таких файлов.

Дополнительные темы безопасности¶

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

• Убедитесь, что ваш код Python находится вне корня веб-сервера. Этот
гарантирует, что ваш код Python случайно не будет представлен в виде обычного текста
(или казнен случайно).
• Будьте осторожны с файлами, загруженными пользователем.
• Django не ограничивает запросы на аутентификацию пользователей. Для защиты от
атаки методом грубой силы на систему аутентификации, вы можете рассмотреть
развертывание подключаемого модуля Django или модуля веб-сервера для регулирования этих запросов.
• Держите свой SECRET_KEY в секрете.
• Рекомендуется ограничить доступность вашей системы кэширования и
базу данных с помощью брандмауэра.
• Взгляните на 10 лучших проектов Open Web Application Security Project (OWASP)
список, который определяет некоторые распространенные уязвимости в веб-приложениях. В то время как
У Django есть инструменты для решения некоторых проблем, другие проблемы должны быть
учтены в дизайне вашего проекта.
• Mozilla обсуждает различные темы, касающиеся веб-безопасности. Их
страницы также включают принципы безопасности, применимые к любой системе.

Django Tutorial Часть 2: Создание скелета веб-сайта — Изучение веб-разработки

Эта вторая статья в нашем Django Tutorial показывает, как вы можете создать «скелетный» проект веб-сайта в качестве основы, который затем можно заполнить настройками для конкретного сайта, путями , модели, представления и шаблоны.

В этой статье показано, как создать «каркасный» веб-сайт, который затем можно заполнить настройками, путями, моделями, представлениями и шаблонами для конкретного сайта (мы обсудим их в следующих статьях).

Для начала:

1. Используйте инструмент django-admin для создания папки проекта, базовых шаблонов файлов и manage.py , который служит сценарием управления вашим проектом.
2. Используйте manage.py для создания одного или нескольких приложений .

   Примечание: Веб-сайт может состоять из одного или нескольких разделов. Например, основной сайт, блог, вики, область загрузок и т. Д. Django рекомендует вам разрабатывать эти компоненты как отдельные приложения , которые затем при желании можно было бы повторно использовать в различных проектах.

3. Зарегистрируйте новые приложения, чтобы включить их в проект.
4. Подключите url / path mapper для каждого приложения.

Для веб-сайта локальной библиотеки папки веб-сайта и проекта называются locallibrary и включают одно приложение с именем catalog .
Таким образом, структура папок верхнего уровня будет следующей:

  локальная библиотека /
    manage.py
    locallibrary /
    каталог/
  

В следующих разделах подробно обсуждаются этапы процесса и показано, как можно протестировать свои изменения.В конце этой статьи мы обсудим другие настройки всего сайта, которые вы также можете выполнить на этом этапе.

1. Откройте командную оболочку (или окно терминала) и убедитесь, что вы находитесь в своей виртуальной среде.
2. Перейдите туда, где вы хотите хранить свои приложения Django (упростите поиск, например, в папке Documents ) и создайте папку для своего нового веб-сайта (в данном случае: django_projects ). Затем перейдите во вновь созданный каталог:

     мкдир django_projects
   cd django_projects
     

3. Создайте новый проект с помощью команды django-admin startproject , как показано, а затем перейдите в папку проекта:

     django-admin startproject locallibrary
   cd locallibrary
     

Инструмент django-admin создает структуру папок / файлов следующим образом:

  локальная библиотека /
    управлять.ру
    locallibrary /
        __init__.py
        settings.py
        urls.py
        wsgi.py
        asgi.py
  

Наш текущий рабочий каталог должен выглядеть примерно так:

  ../django_projects/locallibrary/
  

Подпапка проекта locallibrary является точкой входа на веб-сайт:

• __init__.py — это пустой файл, который указывает Python рассматривать этот каталог как пакет Python.
• настроек.py содержит все настройки веб-сайта, включая регистрацию любых создаваемых нами приложений, расположение наших статических файлов, детали конфигурации базы данных и т. д.
• urls.py определяет сопоставления URL-адресов сайта и просмотра. Хотя это может содержать и код сопоставления URL-адресов, более распространено делегирование некоторых сопоставлений конкретным приложениям, как вы увидите позже.
• wsgi.py используется, чтобы помочь вашему приложению Django взаимодействовать с веб-сервером.Вы можете рассматривать это как шаблон.
• asgi.py — это стандарт для асинхронных веб-приложений и серверов Python для взаимодействия друг с другом. ASGI является асинхронным преемником WSGI и обеспечивает стандарт как для асинхронных, так и для синхронных приложений Python (тогда как WSGI предоставил стандарт только для синхронных приложений). Он обратно совместим с WSGI и поддерживает несколько серверов и платформ приложений.

Сценарий manage.py используется для создания приложений, работы с базами данных и запуска веб-сервера разработки.

Затем выполните следующую команду, чтобы создать приложение каталога , которое будет жить внутри нашего проекта locallibrary . Обязательно запускайте эту команду из той же папки, что и ваш проект manage.py :

  python3 manage.py каталог startapp
  

Примечание: Пример команды для Linux / macOS X. В Windows команда должна быть:

py -3 manage.py каталог startapp

Если вы работаете в Windows, замените python3 на py -3 в этом модуле.

Если вы используете Python 3.7.0 или новее, вам следует использовать только каталог py manage.py startapp

Инструмент создает новую папку и заполняет ее файлами для различных частей приложения (показано в следующем примере).
Большинство файлов названы в соответствии с их назначением (например, представления должны храниться в views.py , модели в models.py , тесты в tests.py , конфигурация сайта администрирования в admin.py , регистрация приложения в приложениях.py ) и содержат некоторый минимальный шаблонный код для работы со связанными объектами.

Обновленный каталог проекта теперь должен выглядеть так:

  локальная библиотека /
    manage.py
    locallibrary /
    каталог/
        admin.py
        apps.py
        models.py
        tests.py
        views.py
        __init__.py
        миграции /
  

Вдобавок теперь у нас:

• Папка migrations , используемая для хранения «миграций» — файлов, которые позволяют автоматически обновлять базу данных по мере изменения моделей.
• __init__.py — пустой файл, созданный здесь, чтобы Django / Python распознал папку как пакет Python и позволял вам использовать его объекты в других частях проекта.

Примечание: Вы заметили, чего не хватает в приведенном выше списке файлов? Хотя есть место для ваших представлений и моделей, вам некуда разместить сопоставления URL-адресов, шаблоны и статические файлы. Мы покажем вам, как создавать их в дальнейшем (они нужны не на каждом веб-сайте, но они необходимы в этом примере).

Теперь, когда приложение создано, мы должны зарегистрировать его в проекте, чтобы оно было включено при запуске любых инструментов (например, при добавлении моделей в базу данных). Приложения регистрируются путем добавления их в список INSTALLED_APPS в настройках проекта.

Откройте файл настроек проекта, django_projects / locallibrary / locallibrary / settings.py , и найдите определение для списка INSTALLED_APPS . Затем добавьте новую строку в конец списка, как показано ниже:

  INSTALLED_APPS = [
    'джанго.contrib.admin ',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    
    'catalog.apps.CatalogConfig',
]
  

В новой строке указывается объект конфигурации приложения ( CatalogConfig ), который был сгенерирован для вас в /locallibrary/catalog/apps.py при создании приложения.

Примечание: Вы заметите, что уже есть много других INSTALLED_APPS (и MIDDLEWARE , далее в файле настроек).Это обеспечивает поддержку сайта администрирования Django и используемых им функций (включая сеансы, аутентификацию и т. Д.).

Это также та точка, где вы обычно указываете базу данных, которая будет использоваться для проекта. По возможности имеет смысл использовать одну и ту же базу данных для разработки и производства, чтобы избежать незначительных различий в поведении. Вы можете узнать о различных параметрах в Базах данных (Django docs).

Мы будем использовать базу данных SQLite для этого примера, потому что мы не ожидаем, что потребуется много одновременного доступа к демонстрационной базе данных, и это не требует дополнительной работы для настройки! Вы можете увидеть, как эта база данных настроена в настройках .py :

  БАЗ ДАННЫХ = {
    'дефолт': {
        'ДВИГАТЕЛЬ': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}
  

Поскольку мы используем SQLite, нам не нужно делать здесь никаких дополнительных настроек. Давайте двигаться дальше!

Файл settings.py также используется для настройки ряда других параметров, но на этом этапе вы, вероятно, хотите изменить только TIME_ZONE — это должно быть сделано равным строке из стандартного списка времени базы данных tz зоны (столбец TZ в таблице содержит нужные вам значения).Измените значение TIME_ZONE на одну из этих строк, соответствующую вашему часовому поясу, например:

  TIME_ZONE = 'Европа / Лондон'
  

Есть два других параметра, которые вы сейчас не измените, но о которых вам следует знать:

• СЕКРЕТНЫЙ КЛЮЧ . Это секретный ключ, который используется как часть стратегии безопасности веб-сайта Django. Если вы не защищаете этот код в процессе разработки, вам нужно будет использовать другой код (возможно, прочитанный из переменной среды или файла) при вводе его в производство.
• ОТЛАДКА . Это позволяет отображать журналы отладки при ошибке, а не ответы с кодом состояния HTTP. Это должно быть установлено на False в производстве, поскольку отладочная информация полезна для злоумышленников, но пока мы можем оставить его равным True .

Веб-сайт создается с помощью файла сопоставления URL-адресов ( urls.py ) в папке проекта. Хотя вы можете использовать этот файл для управления всеми сопоставлениями URL-адресов, чаще всего откладывают сопоставления для связанного приложения.

Откройте locallibrary / locallibrary / urls.py и обратите внимание на учебный текст, в котором объясняются некоторые способы использования сопоставителя URL-адресов.

  "" "Конфигурация URL-адреса локальной библиотеки

Список urlpatterns направляет URL-адреса в представления. Для получения дополнительной информации см .:
    https://docs.djangoproject.com/en/3.1/topics/http/urls/
Примеры:
Представления функций
    1. Добавьте импорт: из представлений импорта my_app
    2. Добавьте URL-адрес в urlpatterns: path ('', views.home, name = 'home')
Представления на основе классов
    1.Добавить импорт: from other_app.views import Home
    2. Добавьте URL-адрес в urlpatterns: path ('', Home.as_view (), name = 'home')
Включение другого URLconf
    1. Импортируйте функцию include (): из импорта django.urls include, path
    2. Добавьте URL-адрес в urlpatterns: path ('blog /', include ('blog.urls'))
"" "
от администратора импорта django.contrib
из пути импорта django.urls

urlpatterns = [
    путь ('admin /', admin.site.urls),
]
  

Сопоставления URL-адресов управляются с помощью переменной urlpatterns , которая представляет собой список Python из функций path () .Каждая функция path () либо связывает шаблон URL-адреса с конкретным представлением , которое будет отображаться при сопоставлении шаблона, либо с другим списком кода тестирования шаблона URL (в этом втором случае шаблон становится «базовым URL «для шаблонов, определенных в целевом модуле). Список urlpatterns изначально определяет одну функцию, которая сопоставляет все URL-адреса с шаблоном admin / с модулем admin.site.urls , который содержит определения сопоставления URL-адресов приложения администрирования.

Примечание: Маршрут в path () — это строка, определяющая шаблон URL для сопоставления. Эта строка может включать именованную переменную (в угловых скобках), например 'каталог / /' . Этот шаблон будет соответствовать URL-адресу типа / catalog / * any_chars * / и передавать any_chars в представление в виде строки с именем параметра id . Мы обсудим методы путей и шаблоны маршрутов далее в следующих разделах.

Чтобы добавить новый элемент списка в список urlpatterns , добавьте следующие строки в конец файла.Этот новый элемент включает путь () , который перенаправляет запросы с шаблоном catalog / в модуль catalog.urls (файл с относительным URL-адресом catalog / urls.py ).

 
из импорта django.urls включить

urlpatterns + = [
    путь ('catalog /', include ('catalog.urls')),
]
  

Примечание: Обратите внимание, что мы включили строку импорта ( из импорта django.urls, включая ) с кодом, который ее использует (так что легко увидеть, что мы добавили), но обычно включают все ваши строки импорта в верхней части файла Python.

Теперь давайте перенаправим корневой URL нашего сайта (т.е. 127.0.0.1:8000 ) на URL 127.0.0.1:8000/catalog/. Это единственное приложение, которое мы будем использовать в этом проекте. Для этого мы будем использовать специальную функцию просмотра, RedirectView , которая принимает новый относительный URL-адрес для перенаправления на ( / catalog / ) в качестве своего первого аргумента, когда шаблон URL-адреса указан в функции path () . совпадает (в данном случае корневой URL).

Добавьте следующие строки в конец файла:

 
из джанго.views.generic импорт RedirectView
urlpatterns + = [
    путь ('', RedirectView.as_view (url = 'catalog /', постоянный = True)),
]
  

Оставьте первый параметр функции пути пустым, чтобы подразумевать ‘/’. Если вы напишете первый параметр как ‘/’, Django выдаст вам следующее предупреждение при запуске сервера разработки:

  Проверка системы выявила некоторые проблемы:

ПРЕДУПРЕЖДЕНИЯ:
?: (urls.W002) Ваш шаблон URL '/' имеет маршрут, начинающийся с '/'.
Удалите эту косую черту, так как в ней нет необходимости.Если этот шаблон нацелен в include (), убедитесь, что в шаблоне include () есть завершающий символ '/'.
  

Django по умолчанию не обслуживает статические файлы, такие как CSS, JavaScript и изображения, но это может быть полезно для веб-сервера разработки, когда вы создаете свой сайт. В качестве последнего дополнения к этому преобразователю URL-адресов вы можете включить обслуживание статических файлов во время разработки, добавив следующие строки.

Добавьте следующий последний блок в конец файла:

 
из джанго.conf настройки импорта
из django.conf.urls.static статический импорт

urlpatterns + = static (settings.STATIC_URL, document_root = settings.STATIC_ROOT)
  

Примечание: Существует несколько способов расширить список urlpatterns (ранее мы просто добавляли новый элемент списка с помощью оператора + = , чтобы четко разделить старый и новый код). Вместо этого мы могли бы просто включить эту новую карту шаблонов в определение исходного списка:

  urlpatterns = [
    путь ('admin /', admin.site.urls),
    путь ('catalog /', include ('catalog.urls')),
    путь ('', RedirectView.as_view (url = 'catalog /')),
] + static (settings.STATIC_URL, document_root = settings.STATIC_ROOT)
  

В качестве последнего шага создайте файл в папке каталога с именем urls.py и добавьте следующий текст, чтобы определить (пустой) импортированный urlpatterns . Здесь мы будем добавлять наши шаблоны по мере создания приложения.

  из пути импорта django.urls
из . импорт просмотров

urlpatterns = [

]
  

На данный момент у нас есть готовый каркасный проект.На самом деле веб-сайт еще ничего не делает для , но стоит запустить его, чтобы убедиться, что ни одно из наших изменений ничего не сломало.

Прежде чем мы это сделаем, мы должны сначала запустить миграцию базы данных . Это обновляет нашу базу данных (для включения любых моделей в наши установленные приложения) и удаляет некоторые предупреждения сборки.

Запуск миграции базы данных

Django использует объектно-реляционное сопоставление (ORM) для сопоставления определений моделей в коде Django со структурой данных, используемой базовой базой данных.Когда мы меняем определения нашей модели, Django отслеживает изменения и может создавать сценарии миграции базы данных (в / locallibrary / catalog / migrations / ) для автоматического переноса базовой структуры данных в базе данных в соответствии с моделью.

Когда мы создавали веб-сайт, Django автоматически добавил несколько моделей для использования в разделе администрирования сайта (который мы рассмотрим позже). Выполните следующие команды, чтобы определить таблицы для этих моделей в базе данных (убедитесь, что вы находитесь в каталоге, содержащем manage.py ):

  python3 manage.py makemigrations
python3 manage.py мигрировать
  

Предупреждение: Вам нужно будет запускать эти команды каждый раз, когда ваши модели изменяются таким образом, что это повлияет на структуру данных, которые необходимо сохранить (включая как добавление, так и удаление моделей целиком и отдельных полей).

Команда makemigrations создает (но не применяется) миграции для всех приложений, установленных в вашем проекте.Вы также можете указать имя приложения, чтобы просто запустить миграцию для одного проекта. Это дает вам возможность проверить код этих миграций, прежде чем они будут применены. Если вы эксперт по Django, вы можете немного подправить их!

Команда migrate — это то, что применяет миграции к вашей базе данных. Django отслеживает, какие из них были добавлены в текущую базу данных.

Примечание. Дополнительную информацию о менее используемых командах миграции см. В разделе «Миграции» (документация Django).

Запуск веб-сайта

Во время разработки вы можете обслуживать веб-сайт сначала с помощью веб-сервера разработки , а затем просматривать его в локальном веб-браузере.

Примечание: Веб-сервер разработки не является надежным и недостаточно производительным для производственного использования, но это очень простой способ запустить и запустить ваш веб-сайт Django во время разработки, чтобы быстро протестировать его. По умолчанию он будет обслуживать сайт на вашем локальном компьютере ( http: // 127.0.0.1: 8000 /) , но вы также можете указать другие компьютеры в вашей сети для обслуживания. Для получения дополнительной информации см. Django-admin и manage.py: runserver (документы Django).

Запустите веб-сервер разработки , вызвав команду runserver (в том же каталоге, что и manage.py ):

  сервер запуска python3 manage.py

 Выполнение системных проверок ...

 Проверка системы не выявила проблем (0 отключено).
 15 августа 2018 года - 16:11:26
 Django версии 2.1, используя настройки 'locallibrary.settings'
 Запуск сервера разработки по адресу http://127.0.0.1:8000/
 Закройте сервер, нажав CTRL-BREAK.
  

После запуска сервера вы можете просмотреть сайт, перейдя по адресу http://127.0.0.1:8000/ в локальном веб-браузере. Вы должны увидеть страницу с ошибкой сайта, которая выглядит так:

Не волнуйтесь! Эта страница с ошибкой ожидается, потому что у нас нет страниц / URL-адресов, определенных в модуле catalog.urls (на который мы перенаправляемся, когда получаем URL-адрес корня сайта).

Примечание: Страница примера демонстрирует замечательную функцию Django — автоматическое ведение журнала отладки. Когда страница не может быть найдена, Django отображает экран ошибки с полезной информацией или любой ошибкой, вызванной кодом. В этом случае мы видим, что предоставленный нами URL не соответствует ни одному из наших шаблонов URL (как указано в списке). В производственной среде ведение журнала отключено (когда мы размещаем сайт в Интернете), и в этом случае будет отображаться менее информативная, но более удобная для пользователя страница.

На данный момент мы знаем, что Django работает!

Примечание: Вам следует повторно запустить миграцию и повторно протестировать сайт всякий раз, когда вы вносите существенные изменения. Это не займет много времени!

Каталог / содержит файлы для представлений, моделей и других частей приложения. Откройте эти файлы и проверьте шаблон.

Как вы видели ранее, сопоставление URL-адресов для сайта администратора уже добавлено в URL-адреса проекта .py . Перейдите в область администратора в своем браузере и посмотрите, что произойдет (вы можете вывести правильный URL-адрес из сопоставления).

Вы создали законченный скелет проекта веб-сайта, который можно заполнить URL-адресами, моделями, представлениями и шаблонами.

Теперь, когда каркас веб-сайта локальной библиотеки готов и работает, пора приступить к написанию кода, который заставляет этот веб-сайт делать то, что он должен делать.

Django — полный стек Python

Django — широко используемый веб-сайт Python.
фреймворк приложения с философией «батарейки включены».Принцип
за включенными батареями является то, что общая функциональность для построения
веб-приложения должны поставляться с фреймворком, а не как отдельные
библиотеки.

Например,
аутентификация,
URL-маршрутизация, a
шаблонизатор,
объектно-реляционный преобразователь (ORM),
и миграции схемы базы данных
все включены в структуру Django.
Сравните эту включенную функциональность с фреймворком Flask, для которого требуется
отдельная библиотека, такая как
Flask-Войти
для аутентификации пользователя.

Философия включения батарей и расширяемости — это просто две разные
способы решения проблемы построения каркаса. Ни одна из философий по своей сути не лучше
чем другой.

Почему Django — хороший выбор веб-фреймворка?

Стабильность, производительность и сообщество проекта Django выросли
чрезвычайно за последнее десятилетие с момента создания фреймворка. Подробно
учебные пособия и передовой опыт легко доступны в Интернете и в книгах.
Фреймворк продолжает добавлять важные новые функции, такие как
миграции базы данных
с каждым выпуском.

Я настоятельно рекомендую фреймворк Django в качестве отправной точки для новой сети Python.
разработчиков, потому что официальная документация и руководства являются одними из
лучше всего в разработке программного обеспечения. Во многих городах также есть Django-specific
такие группы, как Django District,
Джанго Бостон и
Сан-Франциско Джанго
чтобы новые разработчики могли получить помощь, когда они застряли.

Книги и руководства по Django

Существует множество бесплатных или недорогих ресурсов для Django. Делать
обязательно проверяйте номера версий, используемые в каждом сообщении, которое вы читаете, потому что
Django был выпущен более 10 лет назад и имел огромное количество обновлений.
с того времени.Эти ресурсы предназначены для новичков. Если ты уже
имеют опыт работы с Django, вам следует взглянуть на следующий раздел
ресурсы для более сложных руководств.

Django видео

Вы ищете видео по Django в дополнение к статьям? Есть специальный
раздел для Django и веб-разработки на
страница лучших видеороликов Python.

Темы Django среднего и продвинутого уровней

Эти книги и руководства предполагают, что вы знакомы с основами строительства.
Django и хотим пойти дальше, чтобы узнать больше о
каркас.

• 2 шарика Django
Дэниела Гринфельда и Одри Рой стоит денег на вход, если
вы серьезно относитесь к тому, чтобы научиться правильно разрабатывать веб-сайты Django.

• Разработка через тестирование с помощью Django, Django REST Framework и Docker
подробности курса, как настроить среду разработки с Docker в
чтобы создать и развернуть RESTful API на базе Python, Django,
и Django REST Framework.

• Взаимодействие пользователя с формами
объясняет общий ввод веб-форм, как Django обрабатывает формы через запросы POST,
различные типы ввода, такие как CharFields, DateFields и EmailFields,
и проверка этого ввода.

• Это руководство по оптимизации проекта Django, состоящее из трех частей, охватывает широкий спектр
продвинутые темы, такие как
Профилирование и настройки Django,
работа с базами данных
и кеширование.

• Кэширование в Django подробно описано
посмотрите конфигурацию, необходимую для кэширования, и как измерить
повышение производительности после его установки.

• ментальных моделей для взглядов, основанных на классах
предоставляет некоторые точки сравнения между представлениями на основе классов (CBV) и
представления, основанные на функциях, и мнения авторов о том, как можно лучше
понимать CBV.

• Работа с часовыми поясами необходима каждому веб-приложению. Этот
сообщение в блоге на pytz, а Django — это
отличное начало для выяснения того, что вам нужно знать.

• Руководство по ASGI в Django 3.0 и его производительности
охватывает новый интерфейс асинхронного серверного шлюза (ASGI), который был
введен в Django 3.0 и объясняет некоторые нюансы и подводные камни
что вам следует учитывать, если вы решите использовать его для своих веб-приложений.

• REST API с Django: создание мощных веб-API с Python и Django
Уильям С.Винсент — это книга для тебя
если вы просто выходите за рамки основ Django и хотите получить
ускорение с помощью Django REST Framework (DRF)
и сервис-ориентированная архитектура (SOA). Он также погружается в более продвинутые
такие темы, как аутентификация на основе токенов и разрешения.

• Учебное пособие по Django Stripe
подробно описано, как быстро добавить Stripe для приема платежей в веб-приложении Django.

• Этот учебник по Python Social Auth для Django
покажет вам, как интегрировать кнопки входа в социальные сети в ваш Django
заявление.

• Обновление Django
предоставляет пошаговое руководство по обновлению ваших проектов Django ‘
код.

• Поваренная книга администратора Django
а также
Создание многопользовательских приложений с помощью Django
две надежные бесплатные книги с открытым исходным кодом в стиле «рецептов кода», которые научат
вы больше об интерфейсе администратора, а также о создании проектов, которые
будут использоваться более чем одним клиентом, поэтому их данные должны быть
правильно разделены.

• Как создавать собственные команды управления Django
объясняет, как расширить управление по умолчанию .py список команд с вашим
собственные пользовательские команды в ваших проектах. В учебнике есть множество замечательных
примеры с ожидаемым результатом, чтобы упростить изучение и изучение
пока прорабатываешь пост.

• Люк Плант пишет о
его подход к классовым представлениям (CBV),
которые часто вызывают жаркие споры в сообществе Django о том,
экономят время или «слишком много магии» для фреймворка.

• Контрольный список приложений Django
дает некоторые передовые правила для создания многоразовых приложений Django.

Миграции Django

• Пол Халлетт написал
подробное руководство по обновлению приложения Django 1.7
в блоге Twilio из своего опыта работы с django-twilio
упаковка.

• Учебник по миграции Real Python
исследует разницу между миграциями Юга и встроенными
Миграции Django 1.7, а также то, как вы их используете.

• Серия Эндрю Пинкхэма «Обновление до Django 1.7» — отличное обучение
материал для понимания того, что изменилось в этом основном выпуске и
как адаптировать ваш проект Django.Часть 1,
часть 2 и
часть 3
а также
часть 4
теперь все доступны для чтения.

• миграции Django без простоев
показывает один из возможных способов выполнения миграции схемы в режиме онлайн с помощью
Джанго.

• Как расширить модель пользователя Django
представляет четыре основных способа расширения встроенной модели User , которая
упакован с Django. Этот сценарий очень распространен для всех, кроме
простейшие проекты Django.

• Создание пользовательской модели пользователя в Django
рассматривает, как создать пользовательскую модель пользователя в Django, чтобы электронное письмо
адрес можно использовать в качестве основного идентификатора пользователя вместо
имя пользователя для аутентификации.

Каналы Django

Каналы — это новый механизм в Django 1.9, представленный как отдельное приложение.
Они могут быть включены в базовую структуру в версии 2.0+. Каналы предоставляют
полнодуплексная связь в режиме реального времени между браузером и сервером
на основе WebSockets.

Тестирование Django

Django с фреймворками JavaScript MVC

Существуют ресурсы для фреймворков JavaScript MVC, такие как
Angular, React и Vue.js
на соответствующих страницах.

Руководства по Django ORM

Django обычно имеет собственный объектно-реляционный преобразователь (ORM).
называется «Django ORM». Узнать больше о
Django ORM на отдельной странице и в более широком смысле
ORM на
Страница объектно-реляционных сопоставителей Python.

Статические и медиафайлы

Развертывание и обработка статических и мультимедийных файлов может сбивать с толку новых пользователей.
Разработчики Django. Эти ресурсы вместе с
страница со статическим содержимым полезна для выяснения того, как
для правильной обработки этих файлов.

Шаблоны проектов Django

Шаблоны проектов, не путать с
механизм шаблонов, сгенерируйте шаблонный код для
базовый проект Django плюс дополнительные библиотеки, которые часто используются при
разработка веб-приложений.

Примеры проектов Django с открытым исходным кодом

Чтение открытого исходного кода может быть полезно, когда вы пытаетесь понять
как создавать свои собственные проекты. Это краткий список некоторых
примеры реальных приложений и многое другое можно найти на
Примеры проектов Django и кодовая страница.

• Openduty — проверка статуса сайта
и система оповещения, аналогичная PagerDuty.

• Courtside — это спортивная сеть.
приложение написано и поддерживается автором PyCoder’s Weekly.

• Эти два веб-приложения системы интерактивного голосового ответа (IVR) Django
репозитории часть 1 и
Часть 2 покажет вам, как
создать действительно крутое приложение Django. Также есть сопутствующий
Сообщение блога
с подробными объяснениями каждого шага.

• Тайга — управление проектами
инструмент, созданный с использованием Django в качестве бэкэнда и AngularJS в качестве интерфейса.

• Chowist — это веб-приложение
который воспроизводит основные функции Yelp и добавляет еще пару колокольчиков
и свистки.

Открытый исходный код для изучения Django

Есть много проектов с открытым исходным кодом, которые полагаются на Django.
Один из лучших способов научиться пользоваться этим фреймворком — это прочитать
как другие проекты используют его в реальном коде.В этом разделе перечислены
эти примеры кода по классам и методам в базе кода Django.

Джанго:
Расширения, плагины и связанные библиотеки и
Примеры проектов и кода


django.apps.config AppConfig

django.conf
настройки,
urls.url


django.contrib.admin
filter.SimpleListFilter,


django.contrib.admin.helpers
ActionForm,
AdminForm


django.contrib.admin.options
IS_POPUP_VAR,
IncorrectLookupParameters,
ModelAdmin,
csrf_protect_m


джанго.contrib.admin.sites
Не зарегистрирован,
регистр,
сайт


django.contrib.auth
get_user_model,
декораторы login_required,
хешеры make_password


django.contrib.staticfiles
искатели,
.finders BaseFinder,
.finders BaseStorageFinder,
.finders найти,
.finders get_finders
.handlers StaticFilesHandler
место хранения
.storage CachedStaticFilesStorage,
.storage HashedFilesMixin,
.storage ManifestStaticFilesStorage,
.storage StaticFilesStorage,
.storage staticfiles_storage
.utils match_patterns


джанго.основной
кеш
чеки,
исключения,
Почта,
mail.send_mail,
mail.messages EmailMessage,
управление,
management.base BaseCommand,
сериализаторы,
сигналы,
подписание
валидаторы


django.core.exceptions
DisallowedRedirect,
FieldDoesNotExist,
FieldError,
Неправильно настроен,
Промежуточное ПО не используется,
NON_FIELD_ERRORS,
ObjectDoesNotExist,
Доступ запрещен,
SuspiciousFileOperation,
SuspiciousMultipartForm,
Ошибка проверки


django.db
DEFAULT_DB_ALIAS,
DataError,
Ошибка базы данных,
IntegrityError,
OperationalError,
ProgrammingError,
связь,
связи,
миграции
роутер
сделка
.бэкэнд-утилиты


django.db.migrations
RunPython,
.autodetector MigrationAutodetector,
.exceptions IrreversibleError,
.executor MigrationExecutor,
.loader MIGRATIONS_MODULE_NAME,
.loader MigrationLoader,
.operations.base Operation,
.state ProjectState


django.db.models
АвтоПоле,
BooleanField,
CharField,
DateField,
DateTimeField,
FileField,
Внешний ключ,
GenericIPAddressField,
ImageField,
IntegerField,
Модель,
PositiveIntegerField,
PositiveSmallIntegerField,
сигнал
SlugField,
SmallIntegerField,
Текстовое поле


джанго.db.models.query
BaseIterable,
EmptyQuerySet,
МодельIterable,
Предварительная выборка,
Q,
QuerySet,
prefetch_related_objects


django.db.models.query_utils
DeferredAttribute,
PathInfo,
Q


django.db.models.signals
post_delete,
post_save,
pre_delete,
pre_save


django.dispatch.dispatcher Сигнал

django.forms
Базовая форма,
BooleanField,
CharField,
CheckboxInput,
CheckboxSelectMultiple,
ChoiceField,
DateField,
DateInput,
DateTimeField,
EmailField,
Поле,
FileInput,
FilePathField,
Форма,
Скрытый ввод,
ImageField,
IntegerField,
СМИ,
MediaDefiningClass,
ModelChoiceField,
МодельФорма,
ModelMultipleChoiceField,
MultipleChoiceField,
Выбирать,
SelectMultiple,
TypedChoiceField,
Ошибка проверки


джанго.http
HttpResponse,
HttpResponseBadRequest,
HttpResponseForbidden,
HttpResponseNotModified,
Http404,
HttpResponsePermanentRedirect,
HttpResponseRedirect


django.shortcuts
get_list_or_404,
get_object_or_404,
перенаправление
оказывать,
resolve_url


django.template.base
Контекст,
FilterExpression,
Узел,
NodeList,
Парсер,
Шаблон,
TemplateSyntaxError,
TextNode,
Токен,
TokenType,
VariableDoesNotExist,
VariableNode,
token_kwargs


django.template.context
Контекст


джанго.template.defaultfilters
побег,
формат файла,
безопасно,
забивать
полоски
заглавие,
truncatechars


django.template.loader
get_template,
render_to_string,
select_template


django.template.loader_tags
BlockNode,
ExtendsNode,
IncludeNode


django.template.loaders.filesystem
Загрузчик


django.template.response
SimpleTemplateResponse,
TemplateResponse


django.urls
URLPattern,
URLResolver,
clear_url_caches,
get_callable,
get_resolver,
get_script_prefix,
включают,
дорожка,
re_path,
register_converter,
решать,
задний ход,
reverse_lazy


джанго.urls.exceptions
NoReverseMatch,
Резольвер404


django.utils
Формат даты,
dateparse,
datetime_safe,
форматы,
module_loading,
termcolors,
часовой пояс,
перевод,
дерево


django.utils.cache
add_ Never_cache_headers,
cc_delim_re,
patch_cache_control,
patch_response_headers,
patch_vary_headers


django.utils.crypto
constant_time_compare,
get_random_string


django.utils.datastructures
MultiValueDict


django.utils.dateparse
parse_datetime,
parse_duration


джанго.utils.dates
МЕСЯЦЫ


django.utils.datetime_safe
дата и время


django.utils.decorators
method_decorator


django.utils.deprecation
Промежуточное ПО
RenameMethodsBase


django.utils.duration
duration_string


django.utils.encoding
DjangoUnicodeDecodeError,
filepath_to_uri,
force_bytes,
force_str,
force_text,
iri_to_uri,
is_protected_type,
smart_bytes,
smart_str,
smart_text,
uri_to_iri


django.utils.formats
get_format,
localize_input,
sanitize_separators


джанго.utils.functional
LazyObject,
Обещать,
SimpleLazyObject,
keep_lazy,
ленивый,
total_ordering,
обертывания


django.utils.html
conditional_escape,
побег,
escapejs,
format_html,
format_html_join,
mark_safe,
smart_urlquote,
strip_tags


django.utils.http
base36_to_int,
http_date,
int_to_base36,
is_safe_url,
не цитировать
url_has_allowed_host_and_scheme,
urlencode,
urlquote,
urlunquote


django.utils.ipv6
clean_ipv6_address


django.utils.itercompat
is_iterable


джанго.utils.module_loading
autodiscover_modules,
import_string,
module_has_submodule


django.utils.numberformat
формат


django.utils.safestring
SafeData,
SafeText,
mark_safe


django.utils.termcolors
раскрашивать


django.utils.text
Truncator,
capfirst
format_lazy,
get_text_list,
get_valid_filename,
забивать


django.utils.timezone
get_current_timezone,
поставить в известность,
Теперь,
timedelta


django.utils.translation
LANGUAGE_SESSION_KEY,
активировать,
deactivate_all,
get_language,
get_language_from_request,
gettext,
gettext_lazy,
ngettext,
переопределить
pgettext,
pgettext_lazy,
ugettext,
ugettext_lazy,
ungettext,
ungettext_lazy


джанго.utils.version
get_complete_version


django.views
csrf
.debug get_default_exception_reporter_filter
.decorators.csrf csrf_exempt
.decorators.debug чувствительные_пост_параметры
.decorators.http require_GET,
.decorators.http require_POST


django.views.generic
CreateView,
DeleteView,
DetailView,
FormView,
Посмотреть список,
RedirectView,
TemplateView,
UpdateView,
Вид


django.views.generic.base
RedirectView,
TemplateResponseMixin,
TemplateView,
Вид


джанго.views.generic.detail
SingleObjectMixin


django.views.generic.edit
CreateView,
DeleteView,
DeletionMixin,
FormMixin,
FormView


django.views.generic.list
Посмотреть список,
MultipleObjectMixin


django.views.i18n
JavaScriptCatalog


django.views.static
обслуживать,
was_modified_since


Что вам нужно узнать дальше для вашего приложения Django?

Мое приложение работает, но выглядит ужасно. Как мне стилизовать пользовательский интерфейс?

Как мне интегрировать существующие веб-API в мое приложение?

Я создал веб-приложение Python, как мне теперь его развернуть?

Введение · HonKit

Эта работа находится под лицензией Creative Commons Attribution-ShareAlike 4.0 Международная лицензия.
Чтобы просмотреть копию этой лицензии, посетите https://creativecommons.org/licenses/by-sa/4.0/

.

Добро пожаловать

Добро пожаловать в учебник Django Girls! Мы рады видеть вас здесь. 🙂 В этом руководстве мы отправим вас в путешествие под капотом веб-технологий, предлагая вам взглянуть на все части, которые необходимо объединить, чтобы заставить Интернет работать так, как мы его знаем.

Как и все неизвестное, это будет приключение — но не беспокойтесь, поскольку вы уже набрались храбрости, чтобы быть здесь, с вами все будет в порядке.:)

Введение

Вы когда-нибудь чувствовали, что мир все больше и больше связан с технологиями, к которым вы (пока) не можете иметь отношения? Вы когда-нибудь задумывались, как создать веб-сайт, но у вас никогда не было достаточной мотивации, чтобы начать? Вы когда-нибудь думали, что мир программного обеспечения слишком сложен, чтобы вы даже пытались что-то делать самостоятельно?

Что ж, у нас для вас хорошие новости! Программирование не так сложно, как кажется, и мы хотим показать вам, насколько это может быть весело.

Это руководство не превратит вас волшебным образом в программиста.Если вы хотите преуспеть в этом, вам нужны месяцы или даже годы обучения и практики. Но мы хотим показать вам, что программирование или создание веб-сайтов не так сложно, как кажется. Мы постараемся объяснить различные фрагменты, насколько это возможно, чтобы вы не испугались технологий.

Мы надеемся, что сможем заставить вас полюбить технологии так же сильно, как и мы!

Что вы узнаете во время обучения?

После того, как вы закончите обучение, у вас будет небольшое работающее веб-приложение: ваш собственный блог.Мы покажем вам, как разместить его в Интернете, чтобы другие увидели вашу работу!

Это будет (более или менее) выглядеть так:

Если вы работаете с учебником самостоятельно и у вас нет тренера, который поможет вам в случае возникновения каких-либо проблем, у нас есть для вас система чата:. Мы просили наших тренеров и предыдущих посетителей приходить время от времени и помогать другим с обучением! Не бойтесь задать там свой вопрос!

Ладно, начнем с начала…

Следуя руководству дома

Принять участие в семинаре Django Girls — это потрясающе, но мы понимаем, что это не всегда возможно.Вот почему мы рекомендуем вам попробовать выполнить это руководство дома. Для домашних читателей мы в настоящее время готовим видеоролики, которые упростят самостоятельное изучение руководства. Работа над ним все еще продолжается, но скоро на YouTube-канале «Кодирование для девочек» будет рассказано все больше и больше.

В каждой уже рассмотренной главе есть ссылка на нужный видеоролик.

О нас и участие

Это руководство поддерживается DjangoGirls. Если вы обнаружите какие-либо ошибки или захотите обновить руководство, следуйте инструкциям для участников.

Хотите помочь нам перевести руководство на другие языки?

В настоящее время переводы хранятся на платформе Crowdin.com по адресу:

https://crowdin.com/project/django-girls-tutorial

Если вашего языка нет в списке на Crowdin, откройте новый выпуск, сообщив нам язык, чтобы мы могли его добавить.

Руководств по программированию на Python

Веб-разработка Django с использованием Python

Добро пожаловать в обновленную версию веб-разработки на Python с серией руководств по веб-фреймворку Django.В этих уроках мы расскажем обо всем, что вам нужно, чтобы начать работу и познакомиться с веб-фреймворком Django. Для этого мы собираемся создать веб-сайт, похожий на PythonProgramming.net, который позволит нам освещать такие темы, как:

• Базы данных
• Пользователей
• Управление контентом
• динамических страниц

… и многое другое!

Django — это полнофункциональный веб-фреймворк очень «высокого уровня» (выполняет множество задач за вас), предназначенный для того, чтобы позволить вам достичь быстрого развития, а также подготовить вас с самого начала к созданию веб-сайтов, которые будут масштабироваться во времени, и с точки зрения скорости и раздувания кода.

«Веб-фреймворк» — это все, что предоставляет какие-то каркасы, которые помогут вам создать веб-приложение.

Прежде чем начать

Предлагаю вам ознакомиться с основами Python 3.

В этом руководстве я буду использовать Python 3.7 и Django 2.1.4. Чтобы получить Django, просто выполните:

pip install django

Убедитесь, что вы указываете на pip для python 3. В этом руководстве я буду в основном использовать синтаксис, который вам пригодится в Linux.Например, чтобы сослаться на Python 3 в Linux, вы должны сказать python3 . В Windows вместо этого вы бы сделали что-то вроде py -3.7 , которое конкретно ссылается на Python 3.7. В конце концов, вы почти наверняка запустите свой сайт на сервере Linux. По этой причине я собираюсь использовать синтаксис Linux, но очень часто сначала разрабатывают локально, и вы можете использовать для этого любую операционную систему.

Вы можете обнаружить, что если вы просматриваете это руководство спустя много времени после того, как я его рассмотрел, все изменилось с Django.Вы можете либо проверить раздел комментариев к видео, либо получить ту же версию Django, которую я использую, выполнив:

pip install django == 2.1.4

Однако я бы сделал это только в учебных целях. Вы всегда должны стараться использовать последнюю версию, поскольку она будет включать важные изменения, такие как исправления безопасности.

Я буду использовать sublime-text 3 в качестве своего редактора, но вы можете использовать любой редактор, какой захотите. Вы также можете использовать любую операционную систему, какую захотите.Я работал с Django в Windows, Mac и Linux. Все они отлично работают.

Хорошо, если у вас установлен Django, приступим! После установки Django у вас должно быть ключевое слово командной строки: django-admin . Вы можете использовать это, чтобы начать новый проект . Django считает все веб-сайты набором приложений. Рассмотрим веб-сайт, на котором есть форум, магазин и блог. Каждая из этих трех вещей будет считаться отдельным «приложением». Коллекция этих приложений — ваш проект.Итак, приступим к проекту. В вашем терминале / cmd.exe выполните:

django-admin startproject mysite

Вы можете называть mysite bit как угодно, но, похоже, довольно последовательное соглашение называть ваш проект mysite , поэтому я буду придерживаться этого правила.

Команда startproject создаст новый каталог с именем, которое вы назвали своим проектом. В нашем случае это будет mysite .

Каталог вашего проекта называется mysite , а ваше основное приложение также называется mysite .Единственная реальная роль этого «основного приложения», как я его назову, — это связывание других ваших приложений. На самом деле вам не нужно много делать, кроме управления настройками и URL-адресами.

Django должен быть модульным. Когда вы разрабатываете приложение, например форумы для одного веб-сайта, вы сможете легко перенести приложение форума на другой веб-сайт и внедрить его почти сразу.

Хорошо, помня об этом, давайте добавим наше первое реальное приложение в наш проект. Для этого воспользуемся manage.py . Это вспомогательный скрипт на Python, который позволит вам делать что-то в рамках вашего проекта. Сначала мы будем использовать его для создания другого приложения. В терминале / командной строке перейдите в каталог, в котором находится этот файл manage.py , затем выполните:

python3 manage.py startapp main

Вы должны увидеть, что был создан новый каталог с именем main . Итак, теперь верхние уровни структуры вашего проекта выглядят примерно так:

 основной
    -main (каталог, ваше «основное» приложение)
    -mysite (каталог, это ваше новое приложение)
    -управлять.py (вспомогательный скрипт на Python)
 

Хорошо, отлично. Давайте продолжим и запустим наш сервер сейчас. Мы сделаем это с помощью manage.py . Вероятно, вам следует открыть отдельный терминал / командную строку для запуска сервера внутри. Мы продолжим работу сервера на протяжении большей части разработки.

Для запуска сервера выполните:

python3 manage.py сервер запуска

Вы должны увидеть что-то вроде:

 сервер запуска python3 manage.py
Выполнение системных проверок ...

Проверка системы не выявила проблем (0 отключено).У вас 15 непримененных миграций. Ваш проект может работать неправильно, пока вы не примените миграции для приложений: admin, auth, contenttypes, sessions.
Запустите python manage.py migrate, чтобы применить их.
10 января 2019 года - 18:50:09
Django версии 2.1.5 с использованием настроек mysite.settings
Запуск сервера разработки по адресу http://127.0.0.1:8000/
Закройте сервер, нажав CTRL-BREAK. 

На данный момент мы можем не обращать внимания на миграцию, мы поговорим об этом позже. Мы видим, что наш сервер разработки теперь работает по адресу http: // 127.0.0.1: 8000 . Откройте браузер и перейдите по этому адресу. Вы должны увидеть что-то вроде:

Это просто «рабочее» сообщение по умолчанию, которое вы увидите, если еще не обрабатываете домашнюю страницу самостоятельно. Давайте заменим это на что-нибудь свое! С этого момента я оставлю сервер работать в отдельном терминале.

Django использует так называемую парадигму Model View Controller. Каждая страница, которую вы посещаете в приложении Django, скорее всего, использует эти три вещи для предоставления вам данных.

• Модель: абстракция вашей базы данных, которая будет содержать объекты, сопоставленные с вашей базой данных. Например, у нас будет модель / объект «Учебник», «Модель / объект пользователя», модель / объект «Учебная серия» и т. Д. Все, что вам нужно сделать, это определить эти модели, а все остальное Django сделает за вас. Вы даже можете изменить свои модели в дальнейшем, и с помощью миграции Django может помочь вам сделать это за секунды, а не за вероятный час … или более … вам потребуется сделать это самостоятельно.
• Просмотр: Как вы будете представлять данные. Здесь вы фактически будете отображать вещи для пользователя.

Контроллер

• : как вы сопоставляете URL-адреса с представлениями.

Хотя мы называем это MVC (модель, представление, контроллер), вы можете представить, что он работает наоборот. Пользователь посетит URL-адрес, ваш контроллер (urls.py) будет указывать на конкретное представление (views.py). Это представление может (на самом деле НЕ ДОЛЖНО) взаимодействовать с вашими моделями.

Тем не менее, мы можем немного упростить это и просто указать контроллеру на ваше представление, а представление может просто возвращать строку, чтобы мы могли почувствовать, как все взаимосвязано.

Когда вы только начинаете работать с чем-то вроде Django, все эти связи и вещи, которые нам нужно делать, чтобы делать, казалось бы, простые вещи, могут показаться пугающими, и это того не стоит. В других фреймворках отображение простого текста может быть выполнено мгновенно и не требует всей этой возни. В чем преимущество Django, так это не в простых веб-сайтах. Он сияет, когда у вас есть сайт, который со временем вырос, и вы продолжаете добавлять функции … и т. Д., Но тогда у вас огромный беспорядок кода.Django помогает вам поддерживать порядок и заставляет немедленно следовать передовым методам, которые со временем будут масштабироваться. Поначалу это раздражает, но в долгосрочной перспективе оно того стоит. Мне нравится делиться следующим комиксом:

Мы всегда начинаем проекты с лучшими намерениями, но мы, как правило, плохо предвидим. Лучшее, что Django может для вас сделать, — это то, что изначально может вас раздражать: абстракция. Со временем, если вы захотите добавить больше атрибутов своим пользователям? С Django это было бы очень просто.Скажем, вы хотели добавить больше функций, например, более продвинутую панель навигации? Как насчет панели поиска? Как насчет полного редизайна? Через Django все это было бы тривиально.

Хорошо, давайте отобразим простой текст на главной странице. Для этого нам не нужна модель, но нам нужно представление (которое будет определять текст, который мы хотим отобразить) и контроллер, чтобы он указывал на представление на основе URL-адреса. Поскольку я думаю о вещах в порядке пользователя, я бы сначала начал с контроллера. Итак, нам нужно сообщить Django, что домашняя страница должна возвращать какое-то представление.Django начинается с вашего «основного» приложения при поиске URL-адресов. Итак, сначала давайте перейдем к: mysite / mysite / urls.py :

 от администратора импорта django.contrib
из пути импорта django.urls

urlpatterns = [
    путь ('admin /', admin.site.urls),
]
 

Итак, у нас здесь только один URL-адрес, и, очевидно, это какая-то административная страница, которая сейчас не в центре нашего внимания. Итак, что нам нужно сделать, это указать этот URL-адрес на представление. Тем не менее, Django рассматривает веб-сайты как набор приложений. Итак, на самом деле URL-адресов.py внутри вашего «основного» приложения обычно просто указывает на ваши приложения. Как мы указываем на приложение? Мы просто указываем на файл urls.py этого приложения! Итак, давайте просто добавим это:

 от администратора импорта django.contrib
из пути импорта django.urls, включить

urlpatterns = [
    путь ("", include ('main.urls')),
    путь ('admin /', admin.site.urls),
] 

Помимо добавления дополнительного пути, не забудьте также импортировать «include» из django.urls .

Хорошо, теперь django знает, что, когда путь в основном пуст (домашняя страница), нужно заглянуть внутрь основного приложения по его URL-адресам .py , чтобы увидеть, указывает ли этот файл (контроллер) на представление , которое будет некоторой функцией внутри этого приложения views.py .

Нам еще предстоит изменить файл urls.py нашего основного приложения , и мы также не сделали никакого просмотра. Давайте сделаем и то, и другое! Давайте перейдем в наше приложение mysite / main . Мы видим, что здесь уже есть разные вещи … но нет urls.py ! Добавим, что сейчас:

mysite / main / urls.py

 из пути импорта django.urls
из . импорт просмотров


app_name = 'main' # здесь для размещения имен URL.

urlpatterns = [
    путь ("", views.homepage, name = "homepage"),
] 

Импортируем путь так же, как и раньше. Мы импортируем наш вид локально. Мы указываем имя приложения (это не обязательно, но вы можете просто привыкнуть это делать. Позже это станет очень полезным, когда мы захотим динамически ссылаться на URL-адреса). Как я уже сказал, Django очень модульный, и даже если вы хотите изменить пути URL-адресов или использовать чужое приложение, но, возможно, не те же пути URL-адресов, вы можете легко это сделать.По этой же причине мы даем имя в качестве параметра пути . Ладно, отлично! У нас все готово к контроллеру. Когда кто-то посещает домашнюю страницу, Django сначала смотрит на mysite / mysite / urls.py , видя, что он указывает на mysite / main / urls.py , который затем указывает на views.homepage (то есть на функцию, называемую homepage внутри views.py ). У нас это есть? Неа. Давай сделаем это. views.py уже существует здесь, поэтому откройте его, чтобы отредактировать.Должно получиться так:

mysite / main / views.py

 из django.shortcuts import render

# Создайте здесь свои просмотры.
 

Обычно эти представления визуализируют некоторый шаблон HTML и передают некоторые переменные, но мы просто сделаем это очень простым и вернем прямой ответ HTTP. Для этого нам нужно импортировать его:

 из django. Http импорт HttpResponse 

Мы сказали urls.py искать функцию домашней страницы , поэтому давайте определим это:

Домашняя страница

 def (запрос):
    return HttpResponse ("pythonprogramming.чистая домашняя страница! Ничего себе,  #amaze.  ") 

Обратите внимание, что мы передаем запрос . Вы всегда будете передавать это своим представлениям.

Теперь ваши полные views.py должны быть:

mysite / main / views.py

 из django.shortcuts import render
из django.http import HttpResponse

# Создайте здесь свои просмотры.
главная страница def (запрос):
    return HttpResponse ("домашняя страница pythonprogramming.net! Ничего себе,  #amaze. ")
 

Теперь вернитесь в браузер и обновите страницу.Если до этого момента вы хоть раз возились, возможно, вы столкнулись с ошибкой, и вам нужно будет перезапустить сервер, поскольку, скорее всего, вы остановитесь из-за ошибки. Теперь на главной странице вы должны увидеть:

На этом мы остановимся, и я предлагаю вам убедиться, что вы можете сделать все вышеперечисленное без использования учебного пособия. Итак, запустите новый проект, добавьте приложение, настройте файлы url.py так, чтобы домашняя страница указывала на представление, и пусть это представление возвращает простую строку. С этого момента все будет только усложняться, поэтому важно, чтобы вы понимали эти основы до этого момента.Если вы в чем-то не уверены, я настоятельно рекомендую вам задавать вопросы или гуглить, пока вы не станете твердо во всем до этого момента.

По мере нашего продвижения я предлагаю вам продолжать делать это. В конце каждого урока сохраните проект. Затем в следующем руководстве сделайте копию проекта, следуйте инструкциям по руководству, а затем попробуйте сделать это с копией, не обращаясь к руководству. Вы можете забыть пути импорта или имена функций, это нормально. Вы хотите убедиться, что действительно понимаете, какие соединения необходимо установить.

В качестве альтернативы, вы также можете поработать над побочным проектом, который отличается от того, что мы делаем здесь. Следуя приведенным здесь инструкциям, примените его к своему собственному проекту.

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Комментарий *

Имя *

Email *

Сайт