Новая концепция парсинга

Есть у меня одна мысль и я её периодически думаю. И мысль эта про шаблонизаторы PHP и парсер MODX. Ну разные они. Это как видеокамера и фотоаппарат. На видеокамеру снимают кино, на фотоаппарат мультфильмы (по крайней мере, раньше). Можно, конечно, и камеру использовать для покадровой съёмки. Но зачем? Вот такое же ощущение и от гибрида парсера MODX и Fenom. Первый многократно парсит один и тот же контент, а второй вместо то, чтобы один раз скомпилировать php файл, также многократно компилирует кучу файлов на каждую итерацию MODX парсера. Да ещё и смешение синтаксисов обоих шаблонизаторов в одном контенте усугубляет ситуацию.

Некоторые разработчики отказались от использования тегов MODX в пользу фенома. Но это не даёт какого-то положительного эффекта кроме удобства, так как всё равно контент также парсится многократно. И даже наоборот, небольшой проигрыш для кэшированных тегов, так как MODX парсер заменяет свои теги на значения и сохраняет в кэше страницы, а Fenom теги остаются в контенте и при следующем запросе страницы их заново нужно парсить. Благо выполнять их не нужно, так как значения для них кэшируются. Плюс непродуманность в вопросе кэширования Fenom тегов чанков и файловых сниппетов. Я об этом говорил в одном из видео.

Но на данный момент других рабочих вариантов в MODX нет. Есть старенькие modxSmarty, modxTwig и Twiggy. Но они давно не развиваются. Да и просто подключать шаблонизаторы не достаточно — нужно максимально адаптировать к MODX и добавить соответствующие фичи, как это сделано в Fenom. Вот я и решил, что можно было бы добавить пару шаблонизаторов в MODX для конкурентности. Выбрал Smarty и Blade.

Так вот, мысль такая. Если уж добавлять PHP шаблонизаторы, то необходимо изменить механизм парсинга. И мне больше нравится как сделали ребята в Evolution 2.0. Там работает Blade. Работает как и положено php шаблонизатору. Но в нём можно прямо на странице использовать стандартный парсер через отдельную директиву @evoParser. Очень хорошая идея — не многократно гонять контент через парсер, а парсить только отдельные теги.

Для Revo я бы использовал такую же концепцию. Но немного доработал бы. В Evolution для ресурса нужно как обычно создавать шаблон в БД и в нём указывать имя файла, в котором хранится контент шаблона. По типу статического элемента, но без синхронизации контента. Или другой вариант — создавать файл шаблона, в имени которого указывается id ресурса. Например, doc_3.blade.php для ресурса с id=3.

Мне кажется это сложновато. Я хочу предложить другой механизм, позволяющий работать без захода в админку. Например, в консоли создали главные ресурсы и указали им алиасы и URI. А дальше по этим данным менеджер шаблонов находит нужный шаблон для нужного ресурса и отдаёт его шаблонизатору. В таком варианте возможностей открывает больше, чем в Evolution, где нужно в админке или создать обычный шаблон или ресурс, чтобы использовать его id в имени файла.

В моём варианте в том же PhpStorm набросали скрипт для создания ресурсов типа такого

$modx->newObject('modDocument', [
    'pagetitle' => 'Блог',
    'uri' => 'blog/',
    'alias' => 'blog'
    'isfolder' => true,
    'published' => true,
    'content' => 'Содержание ресурса',
    ...
]);
// Лучше для этих целей использовать процессор
$modx->runProcessor('resource/create', $resourceData);

Запускаем его в консоли и определяем конфиг для шаблонов (см. ниже). Заходить в админку на этом этапе не нужно. Дальше менеджер шаблонов подгружает конфиг, который будет выглядеть примерно так

// templates.php
[
    'index.html' => 'имя файла шаблона для главной страницы',
    'about.html' => 'шаблон страницы "О нас"',
    'blog/' => 'шаблон главной страницы блога',
    'blog/{*}' => 'шаблон для всех дочерних ресурсов блога',
    'catalog/{*}/product-[0-9]+' => 'шаблон для продуктов третьего уровня',
    '{*}' => 'шаблон для всех остальных страниц, для которых не подошли указанные условия',
]

Как видите, тут можно использовать регулярные выражения. Похоже на роутинг в Symfony или Laravel. Для любителей кодить в консоли или в IDE такой подход будет значительно ближе и удобнее.

Кстати, в мире фреймворков принято вместо понятия «шаблон» использовать понятие «вид» (view). Правильнее тоже оперировать этим понятием. Так проще будет читать документацию по шаблонизаторам. А шаблоны пусть остаются в админке. Их единственный удел — привязывать ТВшки к ресурсам.

Вот над такой идеей я думаю и в ближайшее время постараюсь продемонстрировать её наглядно хотя бы в упрощённом варианте. А у вас какие мысли?