Сегодня сделал каркас описанной выше концепции парсинга. Пока только со Smarty. Постарался убрать все раздражающие моменты шаблонизации с Феномом.

Во-первых, рекурсивный парсинг заменён на однократный. Во-вторых, теперь нет проблем с кэширование чанков и файловых сниппетов. В-третьих, отказ от шаблонов в БД. Последние нужны только для ТВшек. Ну и наконец, нет проблем с фигурными скобками в javascript.

По итогам тестирования Smarty выигрывает у Fenom при парсинге 100 чанков около 30%. Это с учётом холодного запуска. Со второго просмотра страницы выигрыш составляет уже порядка 50% - 0,0254 сек против 0,0378 сек. Тут я говорю о Fenom из pdoTools, работающий в режиме MODX шаблонизатора.

Сравнивая эти 2 шаблонизатора могу сказать, что у Smarty больше удобных фишек. Следующий на очереди Blade. Обдумываю, не впихнуть ли их в один пакет. Иначе придётся делать 3 пакета. Один, который меняет логику парсинга, от которого будут зависеть 2 других с шаблонизаторами. Дилемма! 🤔

Что интересно, все туториалы и курсы по изучению языков программирования обязательно содержат пример создания TODO функционала. А вот в MODX такого не оказалось. Заговор или модыксеры выше этого? 🤷‍♂️
А мне вот понадобилось.

Привыкаем к шаблонизаторам PHP

https://modzone.ru/blog/2020/09/15/getting-used-to-php-template-engines/

Уже сейчас можно попробовать потестить скорость Smarty и Fenom. Считает среднее на 10 запросов по кругу.

http://s22375.h3.modhost.pro/smarty.html

http://s22375.h3.modhost.pro/fenom.html

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

https://github.com/btmills/geopattern

PHP Шаблонизаторы в MODX. Новая концепция.

https://youtu.be/w2cC2wMrMy0

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

Несколько раз подряд вызывается метод поиска ресурса по uri. Один за другим. Если ресурсы не кэшируются, то все запросы летят в базу. Но это ещё не всё. Если у вас отключено кэширование карты ресурсов, что советуют делать для сайтов, у которых больше тысячи ресурсов, то поиск происходит так - сначала идет поиск ресурса в базе по uri, берётся его id и следом идёт поиск в базе уже по id. Как вам логика? Нравится?
А если ресурс не найден, то начинаются пляски с uri. К нему добавляется или убирается суффикс контейнера. И опять идёт запрос в базу.🙈

В ZoomX я это безобразие выбросил. И ещё добавил FastRoute в приоритетном режиме. Т.е. сначала проверка роутов, а только потом проверка xPDO. Другие аналогичные пакеты вешают обработку на событие OnPageNotFound, что в итоге удлиняет путь запроса. Зачем делать лишнюю работу (проверки, запросы в базу), если правило уже определено! 🤓

Пакет скоро будет готов. Логика всего этого сложная. Пока пишу тесты. Вот такая новость.

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

Но дело в том, что до реализации этой фичи дело не дошло. Интересно, почему?

У кого-нибудь были задачи, где пригодилась бы такая возможность?

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

П.С. Справедливости ради надо сказать, что данное утверждение справедливо (сорри за тавтологию), когда вы работаете без заранее составленного ТЗ.

После долгих разговоров рад сообщить, что первая версия моего компонента для альтернативного подхода к использованию PHP шаблонизаторов готова.

https://modzone.ru/blog/2020/10/23/zoomx-first-release/

Так как с площадки сообщества modx.pro меня попросили, то я начал осваивать другие ресурсы. И вот моя первая статья на Хабре. Прошу поддержать меня, начинающего пугливого хабровчанина.😋

https://habr.com/ru/hub/modx/

Выложил обновлённую версию ZoomX, в которой добавлена пара фич и исправлены некоторые моменты:
- Управление доступностью объекта $modx в шаблонах.
- Исправлен баг с деинсталяцией пакета.
- Добавлен модификатор modx для отдельного парсинга тегов MODX.
- Небольшой рефакторинг и оптимизация.

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

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

https://youtu.be/UCv1mvOmrRU

Друзья! Есть вопрос. Сейчас логика работы MODX требует обязательного наличия ресурса. Если вы запрашиваете несуществующий ресурс, то MODX всё равно вернёт ресурс, указанный для такого случая (настройка error_page). Для случаев, когда нужно настроить собственный роутинг (например, для профиля пользователей) используют событие OnPageNotFound, в котором форвардят на нужный ресурс.

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

Поясню. Например, вы указали роут users/{id} и указали шаблон для вывода. Ресурса с таким URI не существует. Но вместо вывода страницы 404 вы получите указанный шаблон.

Тут надо понимать, что тогда измениться вся логика подготовки ответа. Не будет проверки прав доступа к ресурсу (ведь ресурса нет), не будет стандартного кэширования ресурса, не будет всей последовательности событий (OnWebPageInit, OnLoadWebDocument и т.д.). А значит не будут работать и плагины на эти события. Хотя их можно запустить самосстоятельно. Не будет тегов ресурса ([[*pagetitle]]). Но может это в каких-то случаях (когда нужно просто вывести контент шаблона) и не нужно? В новой версии ZoomX так будет работать с JSON запросами и ответами.

В общем, нужно ваше мнение. Нужна такая возможность и как её лучше сделать? Может включать через специальную системную настройку? Или я переморочился?

Абсолютно каждый разработчик, использующий MODX, периодически встречает в журнале ошибок записи в стиле «Error caching lexicon topic lexicon/ru/core/default», сигнализирующие об ошибке кэширования того или иного топика лексикона. Некоторых разработчиков эти ошибки беспокоят. Вопросы об этом можно найти в разных сообществах MODX. Есть даже обсуждение данного вопроса на GitHub.

https://modzone.ru/blog/2020/12/06/error-caching-lexicon-topic/

ZoomX. Встроенный функционал API. Анонс.

В новой версии добавлен функционал управления API. Теперь не нужно создавать отдельный файл для API запросов. Работаем как обычно - с формы отправляем ajax запрос с относительным URL. Все запросы используют стандартную точку входа index.php в корне сайта. Для API запросов нужно просто указать заголовок ACCEPT со значением "application/json". Управление запросами в роутах. Подробности после выпуска версии.

Ещё в новой версии ZoomX можно будет писать привычные теги MODX.

{'*pagetitle'}
{'%lexicon_entry'}
{'~5'}
{'$chunk'}

И привычней и короче.

Парни, нужно ваше экспертное мнение по webpack. В чем принципиальное преимущество js сборщиков по сравнению, скажем, с php реализациями?