Теория

Введение в деревья

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

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

/
    people/
        nien-nunb/
        laura-roslin/
    events/
        captain-picard-day/
        winter-wrap-up/

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

Узлы и листья

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

Узлы

Родительские узлы в дереве Wagtail, вероятно, захотят организовать и отобразить просматриваемый индекс своих потомков. Например, блогу нужно способ отобразить список отдельных записей.

Родительский узел может предоставить собственную функцию, возвращающую объекты-потомки.

class EventPageIndex(Page):
    # ...
    def events(self):
        # Get list of live event pages that are descendants of this page
        events = EventPage.objects.live().descendant_of(self)

        # Filter events list to get ones that are either
        # running now or start in the future
        events = events.filter(date_from__gte=date.today())

        # Order by date
        events = events.order_by('date_from')

        return events

Этот пример гарантирует, что возвращаемые объекты ограничены элементами контента, которые имеют смысл, в частности, теми, которые были опубликованы через интерфейс администратора Wagtail (live()) и являются потомками этого узла (descendant_of(self)). Установив свойство класса subpage_types, вы можете указать, какие модели разрешено устанавливать в качестве потомков, а установив свойство класса parent_page_types, вы можете указать, какие модели разрешено устанавливать в качестве родителей этой модели страницы. Wagtail по умолчанию разрешит любую модель, производную от Page. В любом случае, для родительской модели разумно предоставить индекс, отфильтрованный для удобства восприятия.

Листья

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

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

Модель листа может предоставить функцию, которая проходит по дереву в обратном направлении и возвращает соответствующего предка:

class EventPage(Page):
    # ...
    def event_index(self):
        # Find closest ancestor which is an event index
        return self.get_ancestors().type(EventIndexPage).last()

Если определены, subpage_types и parent_page_types также ограничат разрешенные родительские модели, содержащие лист. В противном случае Wagtail позволит связывать любые комбинации родителей и листьев в дереве Wagtail. Как и в случае с страницами-индексами, разумно убедиться, что индекс действительно содержит ожидаемую модель, содержащую лист.

Другие отношения

Ваши модели, производные от Page, могут иметь другие взаимосвязи, которые расширяют базовое дерево Wagtail или вообще от него отличаются. Вы можете предоставить функции для навигации между братьями и сестрами, такие как ссылка «Следующая запись» на странице блога (post->post->post). Может иметь смысл, чтобы поддеревья взаимосвязывались, например, в форуме обсуждений (forum->post->replies). Также может быть полезно перепрыгивать по иерархии, так как все объекты определенного класса модели могут взаимосвязываться независимо от своих предков (events = EventPage.objects.all). В основном, модели определяют свои взаимосвязи, возможности действительно безграничны.

Архитектура запроса Wagtail

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

1. Django получает запрос и обрабатывает его через определения маршрутизатора URL-адресов Wagtail
2. Wagtail проверяет хост-имя запроса, чтобы определить, какой Site-запись обработает этот запрос.
3. Начиная с корневой страницы этого сайта, Wagtail обходит дерево страниц, вызывая метод route() и позволяя каждой модели страницы решить, обработает ли она запрос сама или передаст его дочерней странице.
4. Страница, ответственная за обработку запроса, возвращает объект RouteResult из route(), который идентифицирует страницу вместе с любыми дополнительными args/kwargs, которые необходимо передать в serve().
5. Wagtail вызывает serve(), который строит контекст, используя get_context()
6. serve() находит шаблон для передачи его с помощью get_template()
7. Объект ответа возвращается serve(), и Django отвечает запросу.

Вы можете применить пользовательское поведение к этому процессу, переопределяя методы класса Page такие как route() и serve() в своих собственных моделях. Примеры см. в Рецептах.

Планирование публикации

Публикацию страницы можно запланировать через функцию «Дата/время выхода в эфир» во вкладке «Настройки» на странице «Редактировать». Это позволяет предварительно настроить первоначальную публикацию страницы или обновление страницы. Для публикации страниц в запланированное время необходимо настроить команду управления publish_scheduled_pages.

Основной рабочий процесс следующий:

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

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