Свой шаблонизатор в php

[25517]

Всем доброго времени суток.

Встал вопрос по написанию своего шаблонизатора в php.

Хотелось бы написать аналог шаблонизатора xenforo.

Т.е.

<xf:title>{{ phrase('two_step_verification') }}</xf:title>
<xf:wrap template="account_wrapper" />
<xf:if is="$backupAdded">     <div class="blockMessage blockMessage--important blockMessage--iconic">      {{ phrase('verification_backup_codes_automatically_generated') }}      <a href="{{ link('account/two-step/manage', {'provider_id': 'backup'}) }}">{{ phrase('view_your_backup_codes') }}</a>      <a href="{{ link('account/two-step/backup-codes') }}" data-xf-click="overlay" data-overlay-config="{{ {'backdropClose': false, 'escapeClose': false}|json }}" data-load-auto-click="true" style="display: none"></a>     </div>
</xf:if>
<xf:description>{{ phrase('two_step_verification_desc') }}</xf:description>
<div class="block">     <div class="block-container">      <div class="block-body">       <xf:foreach loop="$providers" value="$provider" if="$provider.isEnabled() OR $provider.canEnable()">        <div class="block-row block-row--separated">         <div class="contentRow">          <div class="contentRow-main contentRow-main--close">           <div class="contentRow-extra">

Насколько я понимаю, здесь используются термины лексический анализ, парсер и компиляция в php код.

Интересует вопрос, как конкретно это реализовать. Что читать и куда "копать"?

Заранее спасибо за ответ

 

[флоппик]

Читать про лексический анализ, парсеры, кодогенерацию.

 

[25517]

Читать про лексический анализ, парсеры, кодогенерацию.

В целом, общий смысл мне понятен .

Сначала лексический анализ и разбивает код на лексемы.
Парсер берёт лексемы и составляет AST.
И на этом я застрял :/
Нужен пинок под зад и пример.

Я без понятия что именно читать

 

[jonjonson]

Не понятно, зачем это.
А так - берем любой популярный шаблонизатор (например Twig) и смотрим код.

 

[25517]

Не понятно, зачем это.
А так - берем любой популярный шаблонизатор (например Twig) и смотрим код.

Для понимания и умения написания подобного.

Да и мне нравится шаблонизатор у ксена, он удобен и приятен в использовании, как и в целом сам ксен.

 

[WMix]

Парсер берёт лексемы и составляет AST.
И на этом я застрял :/

на основе ast генерим php-код

<title><?= phrase('two_step_verification') ?></title>

и складываем в cache. дальше просто include

 

[ksnk]

Вообще-то по синтаксису - какая то каша. С одной стороны - используются вставки а-ля Twig, с другой - какой-то xml-замес, как будто твиговые условные операторы чем-то хуже.
Если жить нельзя без xml, то почему бы не выкинуть твиговость ? как нибудь так...

<xf:title><xf:echo echo="phrase('two_step_verification')"/></xf:title>

 

[Yoskaldyr]

Описанная проблема, не повод использовать что-то отличное от твига, учитывая что твиг можно расширить любыми своими тегами/хелперами и для твига есть полная поддержка в сторме (автокомплит и т.д.)

Единственная причина не использовать твиг это его тормознутость (не излечимая). Но и тут проект должен быть очень специфическим и высоконагруженным, чтобы рендер составлял значительную часть времени выполнения. И я не думаю что это вариант ТС. Но даже если и так есть варианты готовых поддерживаемых решений (из недавно увиденного https://github.com/spiral/stempler)

 

[флоппик]

Твиг транспилится в чистые пхп-шаблоны, не знаю, в чем там тормознутость может быть.

 

[Yoskaldyr]

Твиг транспилится в чистые пхп-шаблоны, не знаю, в чем там тормознутость может быть.

Внимательно смотрим скомпилированный код, включаем профилировщик, и все вопросы пропадут сами собой
Повторюсь что проблему тормознутости можно заметить только на определенных юзкейсах и только под нагрузкой когда быстрый рендер имеет смысл.

 

[25517]

У меня немного другое суждение (=
Да, использовать готовую либу - намного проще.
Но, свой велосипед роднее и с автоподогревом (=
Я именно хочу это реализовать сам.

 

[Фанат]

Внимательно смотрим скомпилированный код, включаем профилировщик, и все вопросы пропадут сами собой
Повторюсь что проблему тормознутости можно заметить только на определенных юзкейсах и только под нагрузкой когда быстрый рендер имеет смысл.

А словами сказать, что мы должны там увидеть?
И что имеется в виду под словом "рендер" для скомпилированного шаблона?

 

[Фанат]

У меня немного другое суждение (=
Да, использовать готовую либу - намного проще.
Но, свой велосипед роднее и с автоподогревом (=
Я именно хочу это реализовать сам.

Единственное оправдание делать велосипед - это научиться делать велосипеды и понимать как они ездят

А то что ты сейчас написал - это детский лепет.
Автоподогрев к твигу прикручивается за 5 минут, а вот на велосипед свой ты готовых покрышек не купишь, и как только откатаешь сезон, его придется выбросить.
Поддержкой твига занимается сообщество аз десятков человек, на нее тратятся тысячи человеко-часов.
А твой драндулет встанет колом с выходом новой версии РНР, потому что просто руки не дойдут поправить все устаревшие вызовы и переписать на новый синтаксис.

Не говоря уже о том, что сиденье-то с подогревом, а цепь с занозами - потому что руки никогда не дойдут довести до ума.

 

[25517]

Единственное оправдание делать велосипед - это научиться делать велосипеды и понимать как они ездят

В точку (=

 

[Yoskaldyr]

А словами сказать, что мы должны там увидеть?
И что имеется в виду под словом "рендер" для скомпилированного шаблона?

Под рендером я подразумевал итоговую работу шаблонизатора по генерации итогового html-а. Тот же твиг эту работу называет рендер, смотрим код метода с внезапным названием render класса \Twig\Template. По нему уже понятно в каких случаях шаблоны твига могут тормозить (даже скоплилированные). Но еще раз говорю это бывает очень редко и надо 100 раз подумать прежде чем использовать свой велосипед.

 

[AnrDaemon]

Но, свой велосипед роднее и с автоподогревом (=

Когда лень учить чужое, пилим своё.
В итоге тратим 10+ лет на создание того, что уже 2019 лет как существует.
@See https://en.wikipedia.org/wiki/Not_invented_here

 

[флоппик]

Под рендером я подразумевал итоговую работу шаблонизатора по генерации итогового html-а. Тот же твиг эту работу называет рендер, смотрим код метода с внезапным названием render класса \Twig\Template. По нему уже понятно в каких случаях шаблоны твига могут тормозить (даже скоплилированные). Но еще раз говорю это бывает очень редко и надо 100 раз подумать прежде чем использовать свой велосипед.

Еще раз - эта транспиляция в пхп в твиге трансплилится и кешируется в обычные пхп шаблоны, не твиговые. Это можно даже в билд пайплайне делать, например, чтоб на прод выливать прокомпиленные шаблоны. А с другой стороны - любое серьезное IO с сеткой, запросы к базе - это все в десятки раз медленее, чем шаблонизация.

 

[флоппик]

Сначала лексический анализ и разбивает код на лексемы.
Парсер берёт лексемы и составляет AST.
И на этом я застрял :/
Нужен пинок под зад и пример.

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

 

[Фанат]

Еще раз - эта транспиляция в пхп в твиге трансплилится и кешируется в обычные пхп шаблоны,

Я думаю, он не про код шаблона, а код кэша.
Сейчас посмотрел, у меня в файлах кэша не тупо простыня "под инклюд", а класс, таки наследник \Twig\Template

И я думаю что он намекает про аутпут буфферинг.
Хотя я всё равно не знаю, за счет чего он может тормозить.

 

[флоппик]

Я думаю, он не про код шаблона, а код кэша.
Сейчас посмотрел, у меня в файлах кэша не тупо простыня "под инклюд", а класс, таки наследник \Twig\Template

И я думаю что он намекает про аутпут буфферинг.
Хотя я всё равно не знаю, за счет чего он может тормозить.

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