Дошли руки заняться классом 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 реализациями?

Небольшой субъективный анализ текущих шаблонизаторов, доступных в данный момент для использования в MODX.

https://modzone.ru/blog/2021/01/20/comparison-of-template-engines/

Наконец закончил тестировать новую версию ZoomX. Работы было сделано много. Тестировать уже непросто. Надо переходить на Codeception. Выступил в качестве подопытного кролика - установил на свой сайт и перевёл главную страницу на Smarty. В скорости прирост на уровне погрешности. Но у меня там и нет ничего сложного - один вызов сниппета. А вот с вёрсткой дела повеселее - верстать в PHPStorm быстрее и приятнее. Плюс отличная поддержка Smarty с подсказками и валидацией синтаксиса.

Аякс запросы теперь идут на обычный index.php - написал нужный роут и сразу всё работает. Теперь смело можно переходить на RESTful API. В общем, PHP разработчикам, имеющим опыт работы с фреймворками, понравится. Хватит завидовать Evolution 2/3. Осталось самое сложное - ДОКУМЕНТАЦИЯ 😀

Заметка с коротким описанием функционала, добавленного в новой мажорной версии ZoomX.

https://modzone.ru/blog/2021/02/04/zoomx-2.0-controllers-resful-api/

Обновил документацию. Следующий этап - наглядная демонстрация возможностей.

https://modzone.ru/documentation/zoomx.html

По мотивам комментариев...
В мире PHP шаблонизаторов нет понятия файловых элементов. Это наследство MODX. Его разработчики под давлением общественности в свое время ввели понятие статических элементов. А мы в RU сообществе придумали другой костыль на основе Fenom. Но и то и другое - костыли. В PHP шаблонизаторах место сниппетов занимают сервисы. Сниппет - это говоря откровенно, архаизм. В своё время это было интересным решением, но сейчас разработка пошла по другому пути развития. Появились паттерны, общие стандарты. Нельзя застаиваться в прошлом.

Мы же все понимаем, что ExtJs 3.4 - это что-то из предыдущей жизни. Так вот и чанки со сниппетами - это тоже самое. В современном мире разработки чанки - это подшаблоны, а сниппеты - это сервисы. Развиваясь в этой парадигме вы расширяете себе поле собственной полезности. Людям, окунувшимся в мир современной разработки, уже не хочется загонять себя в узкие рамки правил MODX. Ланец, Наумкин, But1head, Киреев, Воеводский, Кузнецов, Лукьяненко и многие другие из списка разработчиков modx.pro.

ZoomX - это попытка дать таким людям возможность остаться и использовать современные методы разработки. Мы много говорили о MODX3. Многие ещё не оставили надежду. Я уже давно не верю, что он когда-нибудь выйдет. Поэтому делаю свой вклад в его развитие по своему.

Кто-нибудь хоть раз пользовался функционалом прав доступа из компонента AdminTools?

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