Индивидуальное оформление каждого топика в отдельности

Всем привет!

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


Или сделать какую-либо выборку данных и визуализировать ее. В данном случае я сделаю выборку трех последних комментариев и выведу это в VerticalTimeline. И что самое интересное, это выборка в дальнейшем будет постоянно обновляться. Попробуйте добавить свой комментарий :)

Улучшил скрипты. Теперь downtime при деплое проекта составляет всего несколько секунд.
Сегодня опять перебои в работе были. Перенес окончательно prisma-cms.com в докер.
За счет отказа от промежуточных таблиц для связей.
К примеру, Есть Топик, и у него есть свойство КемНаписан (Пользователь). В классической реляционной модели мы в таблице Топика просто добавляли колонку типа user_id, которая ссылалась на таблицу Пользователя через его id. Попутно могли настроить первичные/вторичные ключи, чтобы обеспечить целостность данных.
В итоге у нас было по прежнему две таблицы (Топики и Пользователи). В свою очередь через эту связь мы могли получить Пользователя по Топику, и по Пользователю
получить все его Топики.

В ранних версиях призмы эта связь обеспечивалась не через колонку в Топике, а через промежуточную таблицу ПользовательТопик. Таким образом связь выглядела так: Пользователь - ПользовательТопик - Топик.
Это обеспечивало все варианты связей (один-к-одному, один-ко-многим и многие-ко-многим). Но, это все-таки лишняя таблица, с кучей соответствующих минусов (включая усложнение написания SQL-запросов, в том числе и потому что колонки в таких таблицах имели "интуитивнопонятные" названия типа A и B).
Вот так вот этот ад выглядел: http://joxi.ru/brReEnMhYJ1VkA
А это только часть таких таблиц: http://joxi.ru/a2XWaY6ID1dZWm (имена таблиц связей начинаются с подчеркивания).

Сейчас подобных таблиц осталось всего 13 штук.

В принципе, на сами GraphQL-запросы это почти не повлияло (в плане их написания). То есть если мы раньше писали запрос
query { users ( first: 3 ){ id username Resources ( first: 3 ){ id name } } }
то есть получали список пользователей и их публикации, то оно так и осталось. Просто под капотом на уровне самой призмы работа поменялась. Поэтому, если делать совсем не большой сервис, то это можно было и не брать во внимание. Но когда делаешь что-то побольше, да еще и начинаешь чистые SQL-запросы писать, то новая призма конечно же гораздо лучше себя показывает.


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


А вот так я добавил кастомные поля для редактирования самого топика.

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

По сути данный функционал - это продолжение прошлого анонса, в котором я писал про то, что в самом редакторе появились кнопки добавления дочерних элементов внутри самих компонентов редактора. Как я и писал, функционал этот экспериментальный, но он активно выливается в очень интересные решения, при чем значительно превосходящие даже мои ожидания :) Я не думал, что так быстро получу такой результат. В данной реализации добавляется специальный компонент, который имеет два режима работы:
1. В режиме редактирования шаблона через сам редактор шаблона.
2. В режиме состояния editable компонента EditableObject.

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

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

Тильда отдыхает:)

UPD: Не пытайтесь увидеть новый редактор при редактировании своих старых статей. А то были уже замечены...)) Я для старых топиков оставил старый редактор. На новый перевести их было бы не сложно, но, считаю, это не нужно. Если хотите поиграться с новым редактором, просто создайте черновик и не сохраняйте статью.
А я написал комментарий здесь: https://prisma-cms.github.io

Добавить комментарий