Создание интерфейса администрирования

Цель лекции: Настроить интерфейс администратора; научиться переопределять шаблоны администрирования; ознакомиться с принципами верстки в Django и реализовать верстку страницы отображения твитов пользователя.

Ключевые термины: шаблон, интерфейс, настройка, пользователь, группа, верстка, страница, твит, администрирование, django, python, представление, модель, проект, приложение

Настройка интерфейса администратора

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

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

Настройка страниц листинга

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

• Admin.site.Register(Tweet)
• Admin.site.Register(HashTag)
• Admin.site.Register(userFollower)

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

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

Отредактируем модель Tweet в tweet/admin.py следующим образом:

from django.contrib import admin
from models import Tweet, HashTag
from user_profile.models import UserFollower
#Register your models here
 admin.site.register(Tweet) 
admin.site.register(HashTag) 
admin.site.register(UserFollower)

Добавим новые строчки кода выше строки #Register your models here и обновим код как показано:

from django.contrib import admin 
from models import Tweet, HashTag 
from user_profile.models import UserFollower
class TweetAdmin(admin.ModelAdmin):
listdisplay = ('user', 'text', 'created_date')
# Register your models here.
admin.site.register(Tweet, TweetAdmin) 
admin.site.register(HashTag)
 admin.site.register(UserFollower)

Этот код добавляет дополнительный столбец в представление администратора для класса TweetAdmin ():

class TweetAdmin(admin.ModelAdmin):
list_display = ('user', 'text', 'created_date')

Более того, мы пропустили дополнительный параметр для регистрации вызовов твитов администратора; таким образом, admin.site.register(Tweet) превращается в admin.site.register(Tweet, TweetAdmin). Обновите страницу и посмотрите, что изменилось, как показано на скриншоте.

увеличить изображение

• list_filter: если определено, то создается боковая панель со ссылками. которые можно использовать для фильтрации объектов, привязанных к одному или нескольким полям модели.
• ordering: Поля используются для упорядочивания объектов на странице списка
• search_fields: если определено, то создается поле для поиска, с помощью которого можно искать. Имени поля предшествует знак минус и нисходящий порядок заменяет восходящий для доступных объектов в модели данных, привязанных к одному или нескольким полям модели.

Давайте используем каждый из предыдущих атрибутов на странице отображения твитов. Опять отредактируем модель Tweet в tweet/models.py и добавим следующие выделенные строки:

from django.contrib import admin
from models import Tweet, HashTag
from user_profile.models import UserFollower
class TweetAdmin(admin.ModelAdmin):
list_display = ('user', 'text', 'created_date') 
list_filter = ('user', )
 ordering = ('-createddate', ) 
searchfields = ('text', )
# Register your models here
 admin.site.register(Tweet, TweetAdmin) 
admin.site.register(HashTag) 
admin.site.register(UserFollower)

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

увеличить изображение

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

Переопределение шаблонов администрирования

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

• Windows: C:\PythonXX\Lib\site-packages\django
• UNIX и Linux: /usr/lib/pythonX.X/site-packages/Django
• Mac OS X: /Library/Python/X.X/site-packages/django

(Здесь, X.X является версией Python на вашей системе. Папка site -packages также может быть найдена как dist -packages.)

Если вы не можете найти путь установки Django по умолчанию для вашей операционной системы, выполните поиск файла django-admin.py. Вы получите несколько результатов, но но что вы хотите найти, находится внутри папки под названием bin.

После обнаружения пути установки Django, откройте django/contrib/admin/templates/ и вы найдете шаблоны, используемые приложением администрирования.

В этом каталоге множество файлов, вот самые важные из них:

• аdmin/base_site.html: это базовый шаблон для администрирования. Этот шаблон создает интерфейс. Все страницы наследуют от этого шаблона последующих моделях.
• admin/change_list.html: Этот шаблон генерирует список доступных объектов
• admin/change_form.html: Этот шаблон создает форму для добавления или изменения объекта.
• admin/delete_confirmation. html: Этот шаблон создает страницу подтверждения удаления объекта

Давайте попытаемся настроить один из этих шаблонов. Предположим, что мы хотим изменить строку Django Administration, расположенную в верхней части всех страниц администратора. Чтобы сделать это, создайте папку с именем admin внутри папки templates нашего проекта, и копируйте admin/base_site.html в нее. После этого отредактируйте файл для замены всех экземпляров Django на Django Tweet:

{% extends "admin/base.html" %}
{% load i18n %}
{% block title %}{{ title|escape }} |
{% trans 'Django Tweet site admin' %}{% endblock %}
{% block branding %}
<h1 id="site-name">{% trans 'Django Tweet administration'
%}</>
{% endblock %}
{% block nav-global %}{% endblock %}

Результат будет выглядеть так:

увеличить изображение

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

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

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

Пользователи, группы и разрешения

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

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

Разрешения пользователя

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

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

Чтобы дать новому пользователю достаточно разрешения на изменение модели данных, можно включить флажок Superuser Status , который будет предоставлять новому пользователю полное разрешение на выполнение любой функции по желанию. Этот вариант делает аккаунт столь же мощным, что и аккаунт суперпользователя, которую мы создали командой python manage.py syncdb.

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

• Добавление объекта в модель данных
• Изменение объекта в модели данных
• Удаление объекта из модели данных

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

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

Разрешения группы

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

Создание группы не очень отличается от других моделей данных. Нажмите на Groups на главной странице интерфейса администрирования, а затем выберите команду Add Group. Далее введите имя группы и назначьте некоторые разрешения для группы; Наконец, нажмите кнопку Save.

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

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

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

app.operation_model

Параметр app определяет имя приложения, где располагается модель; параметр operation может принимать значения add, change или delete; параметр model определяет имя модели

Например, чтобы проверить, может ли пользователь добавлять твиты, используйте:

user.has_perm(`tweets.add_tweet` )

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

user.has_perm(`tweets.change_tweet`)

Кроме того, Django предоставляет доступ к функции, называемой декоратором, которая может ограничивать представление для пользователя, имеющего частное разрешение. Декоратор носит имя permission_ required, и он располагается в пакете django.contrib.auth.decorators.

Использовать декоратор так же просто, как мы использовали функцию login_required. Функция декоратора состоит в ограничении страниц для вошедших пользователей. Пусть мы хотим ограничить представление tweet_save_page (в файле tweets/views.py) для пользователей, имеющих разрешение tweet.add_tweet. Чтобы сделать это, мы должны добавить следующий код::

from django. contrib.auth.decorators import permission_required 
@permission_required('tweets.add_tweet', login_url="/login/") 
def tweet_save_page(request):
#  […]

Этот декоратор имеет два параметра: какой разрешение проверяется и куда перенаправить пользователя в случае отсутствия разрешения.

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

Организация содержимого в страницы – верстка

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

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

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

Функциональность разбиения на страницы Django инкапсулируется в классе под названием Paginator, который расположен в пакете django.core.paginator.Давайте изучим интерфейс этого класса , с помощью интерактивной консоли:

from tweet.models import *
from django.core.paginator import Paginator 
query_set = Tweet.objects.all() 
paginator = Paginator(query_set, 10)

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

Давайте посмотрим, как получается информация из объекта Paginator (конечно, результаты будут различными в зависимости от количество закладок, которые у вас есть):

1

>>> paginator.count # Total number of items 
5
# Объектов на первой странице (индексация с нуля)
>>> paginator.objectlist

[<Tweet: #django is awesome.>, <Tweet: I love Django too.>, <Tweet:
Django makes my day.>, <Tweet: #Django is fun.>, cTweet: #Django is fun.>]

 #Существует ли  для первой страницы предыдущая страница?

>>> pagel = paginator.page(1)

 #Хранится ли объект первой страницы в page1
 >>> pagel.has previous ()

False

Существует ли  для первой страницы следующая страница?
>>> pagel.hasnext()

True

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

Давайте применим верстку к одному из наших представлений, к примеру к странице твитов. Откройте файл tweets\views.py и измените представление users_page следующим образом:

Наша страница профиля пользователя представлена следующим кодом:

class Profile(LoginRequiredMixin, View):
"""User Profile page reachable from /user/<usemame> URL""" 
def get(self, request, username): params = diet()
userProfile = User.objects.get username=username) 
userFollower = UserFollower.objects.get(user=userProfile) 
if userFollower.followers.filter(username=request.user.username).exists:         params["following"] = True else:
params["following"] = False
form = TweetForm(initial = {'country':'Global'})
search_form = SearchForm
tweets= Tweet.objects.filter(user=userProfile).order_by('-created_date')
params["tweets"] = tweets
 params["profile"] = userProfile 
params["form"] = form 
params["search"] = search_form
return render(request, 'profile.html', params)

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

class Profile(LoginRequiredMixin, View):
"""User Profile page reachable from /user/<usemame> URL""
 def get(self, request, username): params = dict()
userProfile=User.objects.get (username=username) 
UserFollower = UserFollower.objects.get(user=userProfile)
if UserFollower.followers.filter (username=request.user.username).exists:      params["following"] = True else:
params["following"] = False
form = TweetForm(initial = {'country':'Global'})
search_form = SearchForm
tweets = Tweet.objects.filter(user=userProfile).order_by('-created_date')
paginator=Paginator(tweets,TWEET_PER_PAGE)
page =request.GET.get('page') try:
tweets = paginator.page(page) 
except PageNotAnlnteger:
# If page is not an integer, deliver first page, tweets = paginator.page(1) except EmptyPage:
# If page is out of range (e.g. 9999), deliver last pa of results.
tweets = paginator.page(paginator.num_j?ages)
params["tweets"] = tweets
params["profile"] = userProfile
params["form"] = form
params["search"] = search_form
return render(request, 'profile.html', params)

Следующий фрагмент кода создает разбиение страниц в предыдущем коде.

tweets=Tweet.objects.filter(user=userProfile). order_by('-created_date')
paginator = Paginator(tweets, TWEET_PER_PAGE)
page = request.GET.get('page')
try:
tweets = paginator.page(page) 
except PageNotAnlnteger:

#	 If page is not an integer, deliver first page, tweets = paginator.page(1)
except EmptyPage:
#	 If page is out of range (e.g. 9999), deliver last page of results.
tweets = paginator.page(paginator.num_pages)

Чтобы заставить этот код работать, добавьте в файл settings.py параметр TWEET_PER_PAGE=5, а в предыдущем коде просто добавьте строчку import settings.py в верхней части кода.

Мы считываем переменную page метода get из запроса, который указывает Django, какая страница была запрошена. Мы так же настроили параметр TWEET_PER_PAGE в файле settings.py для показа количества твитов, отображаемых на одной странице. В данном случае, это число рано 5.

Метод paginator = Paginator (tweets, TWEET_PER_PAGE) создает объект разбивки страниц, в котором содержится вся информация о запросе.

Перейдя по URL-адресу user/<username>/?page=<page_number>, страница будет выглядеть как на приведенном скриншоте. Первый скриншот показывает твиты пользователя с указанием номера страницы в URL-адресе.

увеличить изображение

увеличить изображение

Контрольные вопросы

1. Для чего необходимо использовать верстку?
2. Какие разрешения доступны для группы?
3. Какие разрешения можно установить для пользователя?
4. Для чего может понадобиться переопределять шаблон администрирования?
5. Какие типы разрешений существуют?

Упражнения

Упражнение 1.

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

Упражнение 2.

Настройте автоматическую верстку страницы с твитами

Упражнение 3.

Добавьте возможность выдачи страницы с ощибкой 404 в случае, если введен неверный номер страницы

Упражнение 4.

Добавьте отображение электронной почты пользователя на странице изменения твитов

Список тем, эссе

• Разработка библиотеки шаблонов для прототипа системы модерации твитов
• Разработка библиотеки шаблонов для прототипа системы регистрации пользователей(на пользовательских шаблонах)
• Разработка библиотеки шаблонов для продвинутой системы комментирования(на пользовательских шаблонах)
• Разработка библиотеки шаблонов для прототипа системы ведения пользовательских блогов(на пользовательских шаблонах)
• Разработка библиотеки шаблонов для прототипа сервиса мгновенного обмена собщениями(на пользовательских шаблонах)
• Разработка библиотеки шаблонов для прототипа веб-сервиса для хранения изображений(на пользовательских шаблонах)
• Разработка библиотеки шаблонов для прототипа веб-сервиса электронной почты
• Разработка библиотеки шаблонов для прототипа сервиса для ведения списка ежедневных дел
• Разработка библиотеки шаблонов для прототипа сервиса для учета рабочего времени
• Разработка библиотеки шаблонов для приложения для твитов

Краткие итоги

• Установили разрешения для пользователей
• Установили разрешения для пользователей
• Ознакомились с основами веб-верстки
• Применили верстку для страницы отображения твитов
• Изучили принципы настройки интерфейса администратора
• Ознакомились с шаблонами, входящими в состав Django
• Изучили принципы переопределения стандартных шаблонов
• Рассмотрели практический пример переопределения шаблона
• Изучили понятие декоратора
• Рассмотрели типовые запросы для верстки