Новая концепция парсинга
Есть у меня одна мысль и я её периодически думаю. И мысль эта про шаблонизаторы 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). Правильнее тоже оперировать этим понятием. Так проще будет читать документацию по шаблонизаторам. А шаблоны пусть остаются в админке. Их единственный удел — привязывать ТВшки к ресурсам.
Вот над такой идеей я думаю и в ближайшее время постараюсь продемонстрировать её наглядно хотя бы в упрощённом варианте. А у вас какие мысли?
Вы должны авторизоваться, чтобы оставлять комментарии.
Комментарии ()