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

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

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

0   200

Комментарии ()

  1. Семён 07 сентября 2020, 14:10 # 0
    Прикольная идея в один заход делать, я на практике часто встречаю страницы-мутанты, где феномо-модыксовскими парсерами всё по несколько раз обрабатывается. Smarty в свое время Николай Ланец юзал в своем компоненте modxSite, удобно было, хотя это дело вкуса, а ещё у него там была прикольная штука это создание и управление тв-шками, их конфиги задавались в json формате дальше компонент съедал конфиги и делал нужные тв-поля с нужными привязками к шаблонам — это к тому, что было бы вообще прикольно управлять всеми элементами MODX из IDE, а админку оставить только манагерам.
    1. Сергей Шлоков 07 сентября 2020, 20:24 # 0
      Smarty в свое время Николай Ланец юзал в своем компоненте modxSite
      Вместе с phpTemplates. Мне его концепция тоже не очень нравится — нужно создавать шаблон и в его параметрах указывать шаблон Smarty. По ТВшкам интересно. Подумаю.

    Вы должны авторизоваться, чтобы оставлять комментарии.

    Выделите опечатку и нажмите Ctrl + Enter, чтобы отправить сообщение об ошибке.