Альтернативы bemtree

[kompolom]

Уже как то заходила речь о там что было бы круто выполнять bemtree в php. Это бы позволило сильно упростить написание шаблонов и код почище бы стал.

Можете что-то посоветовать, как организовать шаблонизацию не имея bemtree и не усложняя шаблоны блоков?

[qfox]

Про два набора bh-php (один для тегов и стилей, второй для построения дерева) говорить стоит?

[kompolom]

@zxqfox ты имеешь ввиду шаблоны или 2 инстанса $BH?

[qfox]

2 инстанса BH и 2 технологии: bh.php и, условно, bh-tree.php (или bh.tree.php), первый набор из bh.php — из BEMJSON собирает HTML чрез $bh->apply(…), второй — как BEMTREE: прокидывает данные (через $ctx->tParam('data', $data) например, или еще как-то) и строит BEMJSON через $bht->processBemjson(['block' => 'root', 'data' => $data]).

Вторую можно даже на отдельный уровень частично скинуть для специальных блоков под лайаут: l-admin или типа того.

[kompolom]

А какие будут ограничения по сравнению с обычным bemtree? Когда bemtree был асинхронным и блоки могли ходить за данными. Разница была очевидна. Сейчас все +- одинаково будет работать или я что то упускаю? С bemtree очень мало практики было...

[qfox]

@kompolom учитывая, что в пхп походы за данными синхронные — разницы не было даже с асинхронным bemtree. ;-)

[qfox]

А какие будут ограничения по сравнению с обычным bemtree?

Разница примерно такая же, как между BH и BEMHTML. В BEMTREE есть произвольный .match(function() {}), в BH только по блокам/элементам/модификаторам (решается через разводной матчер, который проставляет модификаторы, на которые отдельные матчеры, и через beforeEach — аналог block('*')). Еще нет подпредикатов на .tag, .bem, .cls, .content, etc. Решается через общий матчер, аналог моды .def().

[kompolom]

@zxqfox $bht->processBemjson() вернет строку как я понимаю?

[qfox]

@kompolom нет, оно вернет bemjson. в BH (и BH.PHP) сборка HTML-строки вынесена в отдельную стадию, и это даёт возможность отложить сборку. Например, можно запускать bh.processBemjson, а после этого результат вставлять в posthtml, потому что там аналогичное дерево, которое, правда, не знает про block/elem/mix/etc, но знает про tag, class, attrs ;-). И уже после выполнять bh.toHtml.

[kompolom]

@zxqfox я имею ввиду с точки зрения php это будет строка или массив?

[qfox]

Толи ArrayObject, толи массив из строк и \BEM\Json объектов.

[kompolom]

@zxqfox тоесть двойного преобразования массив->строка->массив->html не будет?

[qfox]

Будет такое: Данные →($bht->processBemjson)→ свернутый ArrayObject<BEM\Json> →($bh->processBemjson)→ Отшаблонизированный ArrayObject<BEM\Json> →($bh->toHtml)→ HTML-строка.

Данные это ассоц. массив с входными данными типа ['block' => 'root', 'user' => $user, 'data' => $data]. Свернутый BEMJSON это то, что обычно лежит в .bemjson.js в бандле. Отшаблонизированный или развернутый BEMJSON это промежуточное вьюориентированное дерево с расставленными tag, attrs, mix, class, и прочим согласно шаблонам, но еще не сконвертированное в строку. Итоговая HTML-строка — обычный результат, который мы обычно видим в .html файле в бандле.

Каждый этап можно отдебажить, вроде бы, не должно быть проблем в реализации в любой CMS.

[kompolom]

@zxqfox а как в первый раз у нас получается свернутый bemjson, а когда ту же функцию еще раз применяем развернутый?

[qfox]

Свернутый-развернутый — это наши условности. processBemjson просто применяет шаблоны, в первом случае это то, что мы положим в $bht, во втором — в $bh (обычные шаблоны). И мы уславливаемся, что в первом случае мы строим дерево и делаем всякую магию (из глобала берем данные, например), чтобы построить дерево, а во втором — превращаем в HTML ($bh->apply это $bh->toHtml($bh->processBemjson($bemjson))). upd: Ну и в первом случае наши шаблоны разворачивают дерево (мы их специально так пишем), а во втором — используем наши обычные шаблоны.

[kompolom]

@zxqfox Спасибо! пошел пробовать..