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. Постараюсь написать обзорную статью про это. На этом всё. Кто считает, что это стоит чашечки хорошего кофе, не стесняйтесь. Могу и коньяку добавить в чашку за ваше здоровье. ))