Вектор на шаблонизаторы PHP

В процессе погружения в тему использования PHP шаблонизаторов в MODX всплывают вопросы, связанные с корректной интеграцией в процесс парсинга. Например, в том же Fenom из компонента pdoTools пацаны из сообщества отмечают ряд нелогичных моментов. Основной — вместо стандартного тега плейсхолдера MODX [[+name]] в каких-то случаях в Fenom используется и такой {$_pls['name']}, и такой {$_modx->getPlaceholder('name')}, и такой {'name' | placeholder} и просто {$name}. В чанках одни правила, в шаблонах и ресурсах другие. Это позиция автора pdoTools. Он выделил Феному второстепенную роль. А за главного — шаблонизатор MODX. Поэтому даже в сниппетах pdoTools шаблонизатор Fenom полноценно не используется — куча чанков вместо одного.

Ещё я встречал код, где вперемешку используется и синтаксис MODX и синтаксис Fenom. А это добавляет путаницы и необходимость помнить последовательность обработки тегов обоими парсерами.

Основные недостатки реализации Fenom (мой мнений) —

• Многократная обработка контента. Т.е. работает парсер MODX и на каждой итерации подключает для обработки Fenom, который вынужден постоянно компилировать один и тот же контент.
• Невозможность использования синтаксиса {$var} в ресурсах и шаблонах как ожидают пользователи фреймворков. Такая возможность есть только в чанках. На моё предложение добавить такую фичу (подключается отдельным модулем) я получил ответ:

  «В MODX мы сами вызываем шаблоны, а не из шаблонов вызываем переменные, как у Smarty и Blade. Так что, я не вижу здесь применения этому плагину.»

  Т.е. кому надо добавят аксессор и мы получим ещё один синтаксис $.var.

• Непроработанные моменты с кэшированием чанков в конструкциях {include '!chunkName'} и {'!chunkName' | chunk}.
• Невозможность вызывать некэшируемые файловые сниппеты.
• Плохая поддержка Fenom в PhpStorm. Хотя это к реализации не имеет отношение.

Что планирую я

На данный момент у Fenom практически нет конкурентов. Поэтому, думаю, ещё парочка (Smarty и Blade) не помешает. Согласно этой статье Smarty самый быстрый шаблонизатор. Ну а Blade очень популярный. Но играть они будут главную роль и по своим правилам, а MODX шаблонизатор остается лишь в качестве воспоминаний. Вдруг кому захочется по-старому вызвать сниппет. Для этого будет отдельный модификатор и блок

{'[[snippet?foo=`bar`]]'|parse}
//или 
{parse}
    [[snippet?foo=`bar`]]
    [[+total]]
{/parse}

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

Так вот, в MODX они хранятся в массиве $modx->placeholders. Это элемент шаблонизатора MODX. Он использует их при парсинге. А другие шаблонизаторы используют свои хранилища таких переменных. И механизм добавления у них другой. К чему я это говорю? Просто описанная в начале статьи ситуация возникает по причине смешивания элементов двух шаблонизаторов. И перевести плейсхолдеры MODX в плейсхолдеры (переменные шаблона) другого шаблонизатора не получится. Ибо все шаблонизаторы PHP компилируют код шаблона в PHP файл и эти переменные становяться переменными PHP. А попробуйте в PHP создать переменную с именем $modx.user.id или $+access_category_enabled или $+modRequest.class. Т.е. это несовместимый элемент шаблонизации.

Но на самом деле это и не нужно. Большая часть плейсхолдеров MODX — это системные настройки, которые можно получить из массива $modx->config. Единственная проблема — некоторые сниппеты результат своей работы сохраняют в плейсхолдер MODX. Поэтому отказаться от них в других шаблонизаторах полностью не получится. Но если усовершенствовать нужный сниппет, то тогда можно полностью отказаться от всех элементов шаблонизатора MODX.

Именно такой подход предлагают ребята из EvolutionCms — полный отказ от встроенного шаблонизатора в пользу Blade. В итоге вы получаете знания из мира современной разработки и легко можете менять системы. И разработчикам из других сообществ гораздо легче адаптироваться — не надо вникать в логику чанков, сниппетов и шаблонов из базы данных. Мне такой подход нравится и в скором времени я выкачу компонент для переноса этой логики в MODX Revolution.

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