Комментарии 11
Судя по всему хороший инструмент, как cms. Чтобы не изобретать велосипед, почему бы и нет. Ещё и на Питоне :)
Напомнило мне Drupal 7, когда я на нём еще писал. Тоже позволяет создавать абстракции на основе Страниц, и тоже требует написания кода для расширения функционала. Интересно, как сейчас дела у Drupal? Очень он мне нравился в своё время
У Drupal хранение контента основа на реляционной БД, что в корне отличается от хранения данных в блобах у Wagtail, о чём я написал ниже
В Drupal 8 поменяли половину ядра, поэтому "вернуться обратно" будет затруднительно из-за высокого порога входа.
Я уже лет пять-шесть как полностью перешел на разработку сайтов на wagtail. Для меня это идеальная система. Да, мгновенно сайт не поднимешь, надо сначала продумать структуру типов контента и блоков, связи между ними и т.д. и потом всё это описать на питоне. Но при этом... большинство вещей делается максимально гибко и буквально описывается несколькими строками кода. Т.е. сайт создается из кубиков, причем кубики легко можно самостоятельно создавать.
И главное механизм наследования можно использовать на всю катушку. Например, я создаю базовый тип страницы с общими заголовочными полями и методами (например формирования хлебных крошек и пр.). Далее создаю контентные типы страниц, наследуясь от базового типа. И т.д.
Механизм StreamFields вообще шикарен: редактор сайта в админке создает контент также из кубиков-блоков, причем блоки вы сами можете создавать (их представление через шаблоны, их логику поведения - всё на питоне). Эти контентные блоки могут быть весьма сложными, могут содержать в себе другие блоки... Т.е. в итоге редактор сайта в админке не в визуальном редакторе произвольно создает контент (что потом вызывает большие проблемы), а создает контент из блоков (а блоки сами знают, как себя представлять, как обрабатывать введенные данные). Например, вам надо в статьи часто вставлять документы, имеющие определенную структуру (превью, название, поля - кому, от кого и т.д.) - вы просто создаете сримфилд-блок с необходимыми полями необходимых типов, создаете шаблон и стили. Всё, теперь редактор просто создает блок и заполняет поля. А как это будет выводиться на сайте, как стилизоваться и пр. - это уже не проблема редактора, редактор работает только с данными, а как они будут выводиться, как будут выравниваться и пр. - об этом вообще не должен думать.
Еще нравится гибкость древовидной структуры: парой строчек кода вы указываете какие страницы (какого типа) могут быть вложены в страницы другого типа. Именно такая гибкость не дает сходу поднять сайт. Одно и то же можно реализовать множеством способов. Поэтому сначала надо подумать, какую структуры (типы данных, связи, структуру вложенности) выбрать.
Есть некоторые вопросы к производительности, но около миллиона структурированных страниц тянет. Для поиска использую elasticsearch. Более миллиона страниц я бы не стал в дереве размещать, лучше ограничиться джанговскими моделями (вагтэйл позволяет без проблем сделать тип страницы, которая будет свои данные по урлу тянуть из джанговской модели).
Судя по миграции:
migrations.CreateModel(
name='PageRevision',
fields=[
#...
('content_json', models.TextField()),
#...
],
),Wagtail хранит весь контент, по сути, в блобах - текстовое поле с JSON. Таким образом взаимодействие с отдельными полями контента будет затруднено - каждый виджет имеет свой формат. Как будет выглядеть SQL запрос выборки значений из страниц с вложенными streamfields и произвольным наполнением контента в них, страшно представить. Но, скорее всего, никак не будет выглядеть - вам придётся строить отдельный бэкенд обработки полей, как это сделано для поиска - для дублирования информации в отдельных таблицах и уже нормальной работой по ним. Поэтому использование elasticsearch "из коробки" выглядит ни разу не фичей, а провалом архитектуры.
Не вижу никаких преимуществ по сравнению с любым SSG, которые позволяют гибко настраивать поля и имеют собственную админку для редактирования контента, например Pelican, если мы говорим про Python или множество других на разных ЯП.
Ещё непонятно как использовать streamfields на фронте - например я хочу сделать сайт с рецептами - чтобы пользователи могли добавлять рецепты, используя streamfields с ограниченным набором кастомных полей (текст, картинки, тэги, ингредиенты и т.п.). Админку, я, во-первых, им давать не хочу, во-вторых, это всё должно быть в интерфейсе сайта, по фэншую. Ну и плюсом надо построить списки по срезам: тэги, ингредиенты, лента. С поиском понятно, а как с остальным решаются вопросы в Wagtail?
Поля типа Streamfild надо использовать не для любых текстовых полей, а для объемных универсальных полей как замену навороченному визуальному редактору (там ведь тоже каша - из html-кода). Но в отличие от визуального редактора, акцент сделан на работу с данными, а не на оформление.
А на фронте я бы не стал использовать streamfield, там достаточно обычных полей. Ведь например в вашем примере с рецептами структура рецептов заранее известна, там гибкость стримфилда не нужна. Да и в бэкэнде я бы наверно для рецептов не задействовал стримфилд.
Стримфилд - это только одна из фич вагтейла. Ее далеко не всегда имеет смысл использовать, т.к. программно работать с ней действительно сложнее.
Ведь например в вашем примере с рецептами структура рецептов заранее известна, там гибкость стримфилда не нужна.
На мой взгляд, очень удобно было бы использовать именно sf на фронте - есть рецепт и пользователь его наполняет: выбрал блок видео - добавил, выбрал текст - добавил, фото, снова видео, блок ингредиентов для теста, блок ингредиентов для начинки и т.д. - самое оно!
Да и в бэкэнде я бы наверно для рецептов не задействовал стримфилд.
Тогда зачем Wagtail? Джанга сама всё умеет. Там тоже есть вложенные формы. Да, не в такой удобной обёртке, но всё же.
Действительно, StreamFields это json и это накладывает некоторые ограничения. Редактирование и создание StreamFields можно осуществлять только из админки Wagtail, беспокоиться об отдельном бэкенд не нужно - Wagtail сам выводит StreamFields в нужном виде - либо как html по заданному шаблону, либо через API в json (все опять же решается парой строк кода из документации). API Wagtail. которые из коробки, доступны только для чтения. Тэги есть - Wagtail использует django-taggit.
Вот мне в этом случае и непонятна целевая аудитория подобного решения, она получается очень узкой - начинающие разработчики на Django, которым надо быстро поднять простой сайт с небольшим набором сложно-сочинённых страниц и чтобы не городить весь этот огород ради небольшого объёма очень удобно использовать streamfield.
Причём, надо заметить, матёрые разрабы на Django уже имеют привычный набор батареек, который позволяет быстро поднять "стандартный сайт".
Здесь было бы уместно упомянуть Django CMS - у неё тоже есть подход к редактированию страниц блоками (или виджетами), но они являются более тонкой прослойкой к Django и не изобретают собственную структуру хранения данных, скорее строят свой редактор контента, который, кстати работает "внутри сайта", без отдельной админки.
Wagtail это не только streamfield. Если Вы не планируете использовать (давать пользователям доступ) админ панель, Wagtail Вам не нужен. Вам нужен хороший API и фронт. Написать такой апи и фронт, на мой взгляд, много работы. Добавьте к этому коллекции изображений и документов, управление доступом к ним различным пользователям и группам, обрезка изображений, черновики и версии страниц и вот Вы получаете весьма сложную структуру, для написание работающей и покрытой тестами версии которой нужно потратить много времени. На Wagtail это можно сделать гораздо быстрее, и значительно меньшим объемом кода. При этом вообще не заморачиваться над фронтом для создания и редактирования страниц/коллекций...
Спасибо за статью, заглянул и в уроки, несколько посмотрел.
Подумал что нашел серебряную пулю... но увы. Для специфичных задач трясогузка не прокатит: мультитеннантность не доделали. Поскольку они используют Django.contrib.sites - то я знаю как допилить, даже статью писал об этом. Но так хотелось готового решения... :'(
Мультиязычность через modeltranlation если в проекте 32 языка замедлит каждое языковое дерево в Pages, так ещё и fallback всей страницы из дерева по умолчанию. Fallback только одного поля - ручками делать. Ну и с мультитеннантностью вообще не работает - одному сайт на хинди второму на немецком, а в модели, да и в админке и хинди и немецкий. Админку конечно можно допилить. Переводные Модели - нет.
Некоторые решения выглядят недоделанно. Pages это микс модели и администратора. Что ж они авторегистрацию полей для бэкэнда не сделали? Например по атрибуту поля модели. Модельные поля у них свои. Любой же атрибут могли добавить.
Бэк вагтайла выглядит благороднее винтажной админки чистого Джанго, но до Админ панели здоровой Python-cms (не существует в природе) ещё далеко.
Wagtail — лучшая CMS на python в нашей галактике