ZoomX. Фреймворковский подход к разработке

Привет, друзья! На днях вышла третья версия компонента ZoomX, которая позволяет взглянуть на разработку в MODX немного под другим углом. Как известно, MODX позиционирует себя не только как CMS, но и как CMF. Но под этим определением скрывается всего лишь возможность использования API MODX. В современном мире разработки при упоминании слова «фреймворк» всплывают другие ассоциации — абстракции, роутинг, сервисный слой, SOLID, тонкие контроллеры, RESTful API и т.п.



Давайте теперь попробуем разобраться какие открываются перспективы.

Разработчикам


Раньше разработчик мог вклиниться в процесс либо с помощью плагина на какое-то событие, либо с помощью сниппета, вставленного на странице. Плагин даёт несколько точек входа. Сниппет — только одну. Это особый элемент, призванный инкапсулировать бизнес-логику, но он срабатывает в момент парсинга (в 99% случаев).

ZoomX к описанным возможностям открывает дополнительную возможность доступа к процессу обработки запроса на этапе инициализации системы, когда запускается маршрутизатор (роутер), в котором для запроса определяется контроллер со сколь угодно сложной бизнес-логикой. Причём можно манипулировать форматом ответа — можно вернуть строку, JSON массив, контент ресурса. А что это даёт? Управляемый RESTful API. И не только для клиентов, но и для управления.

Представим, что есть некий компонент. Пусть это будет бронирование. У него есть настроенное API
GET /booking - список всех броней.
GET /booking/{id} - определённая бронь.
POST /booking - новая бронь
PUT /booking/{id} - изменение определённой брони.
DELETE /booking/{id} - удаление определённой брони.
Тут всё более менее понятно. Но нам нужна ещё страница управления бронью для менеджеров. Сейчас вопрос решается созданием отдельного интерфейса в админке сайта, на которой лежит задача управления сайтом. В итоге админка превращается в проходной двор для разных групп менеджеров — одни контент набивают, другие управляют заказами, третьи ещё чем-нибудь рулят. И там же сидит главный админ и управляет правами всего сайта. И всё это на ExtJs древнейшей версии. Не секрет, что с каждым годом всё труднее найти разраба, готового разобраться в этом ископаемом экземпляре.

Применение REST архитектуры позволяет разрулить данную ситуацию — можно вынести админку на фронт просто создав виртуальную страницу.
GET /book_manage/booking - интерфейс управления бронью.
или так
GET /booking/admin
Она может быть написана с использованием любого современного фреймворка. Поддерживать такое решение гораздо проще. И разработчиков для сопровождения легче найти. Кроме того, это виртуальная страница — для неё не нужно создавать служебный ресурс. А значит и из карты сайта её не нужно убирать. Кстати, тоже самое касается и карты сайта.
$router->get('sitemap.xml', function() {
    zoomx()->autoloadResource(false);   // Отключаем поиск ресурса в базе данных
    $resources = ...    // Получаем список ресурсов    
    return viewx('sitemap.tpl', compact('resources'));
});
Карта виртуальная, формируется динамически и выводится в готовом виде. В обычном же варианте в MODX для этого нужно создавать отдельный служебный ресурс с правильным типом контента.

Верстальщикам


И верстальщикам есть профит от такого подхода. Ведь не нужно сидеть в админке и создавать шаблоны, чанки, сниппеты. Всё можно сделать в любимом редакторе. В ZoomX из коробки есть поддержка шаблонизатора Smarty. В PhpStorm для него есть плагин, в отличие от того же Fenom. Он сильно помогает.
Вместо чанков в Smarty (как и в других PHP шаблонизаторах) используются подшаблоны (файлы). Но есть поддержка и стандартных сниппетов и чанков. Тем, кто работал с Fenom, переучиваться не нужно — сходство максимальное.

Заключение


В общем, цель ZoomX — сократить дистанцию между MODX и современными стандартами разработки. Чтобы разработчик из мира фреймворков мог выбрать MODX для несложного проекта. А MODX разработчик понимал принципы разработки на фреймворках. В своё время, когда я начал изучать Laravel, я был в шоке от того, насколько MODX убог в плане разработки на API. Хотелось бы исключить подобное ощущение у разработчиков MODX.

В данный момент есть документация для второй версии. В третьей версии большой скачок по возможностям. Поэтому документацию нужно изрядно наполнить и отшлифовать. Чем в ближайшее время и займусь. Делать я это буду на ZoomX. Постараюсь написать обзорную статью про это. На этом всё. Кто считает, что это стоит чашечки хорошего кофе, не стесняйтесь. Могу и коньяку добавить в чашку за ваше здоровье. ))
Сергей Шлоков
21 октября 2021, 21:14
modx.pro
2
419
+24
Поблагодарить автора Отправить деньги

Комментарии: 5

Николай Савин
22 октября 2021, 07:47
+2
Огонь! Спасибо за статью, наконец появились примеры из настоящей жизни простого сайта!
Эх в идеальном мире бы серию публикаций в новый раздел «Уроки» — как реализовать сайт при помощи ZoomX
Виталий Киреев
22 октября 2021, 08:07
0
А зачем в этом случае вообще нужен MODX?
    Сергей Шлоков
    22 октября 2021, 09:33
    0
    Я не знаю, что тебе ответить. Если ты правда не понимаешь, в чем я сильно сомневаюсь, то мои объяснения тебя вряд ли убедят. В противном случае это просто тролинг с целью разжечь холивар «Зачем вообще нужен MODX» в стиле Коли Ланца. В этом случае ответ не нужен.
      Николай Савин
      22 октября 2021, 09:49
      +8
      1) Чтобы использовать знакомую экосистему компонентов
      2) Чтобы при работе можно было использовать знакомый API
      3) Ну и админка никуда не делась и какие-то задачи, хотя бы разработчика можно решать внутри
      Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
      5