Есть UMI.CMS, реализую на ней проекты с использованием шаблонизатора XSLT.
Изучая БЭМ и bem-tools пришел к выводу, что создавать XLS-шаблоны без двойной работы не получится и выход использовать BEMHTML.
В теории можно используя API UMI.CMS добавить поддержку BEMHTML (в текущей версии продукта это возможно повлечет к потери официальной поддержки и реализация будет на не публичном АPI системы). В будущей версии продукта это ситуация может измениться, вот официальный анонс:
UMI.CMS 3 — это фреймворк и CMS в одном продукте, который поддерживает все популярные шаблонизаторы: TPL, XSLT, PHP, Twig — а ближайшем будущем — Smarty, Blitz, Fenom. Продукт отличается рекордным быстродействием и невероятным качеством кода.
Источник: UMI.Summit 2013
К сожалению, нет сроков выхода этой версии.
Может быть стоит использовать другие подходы использовать другие подходы. UMI.CMS предоставляет данные страниц, объектов, результаты работы макросов через REST-протоколы (udata, upage, usel, uhttp, ufs и другие) данные могут быть в формате xml или json, это позволяет найти решение использовать UMI.CMS как бекенд GET/POST JSON API и реализовывать проекты на технологиях более совместимых с BEMHTML.
Сейчас в проектах методология БЭМ используется в зачаточном состоянии с использованием собственного сборщика buhges который используется как инструмент верстки совместно с grunt и дополнительными препроцессороми, минимизаторами и п.р. с поддержкой live edit и bower для сторонних библиотек. Это позволяет разбивать верстку на куски сотоящие из html или handlebars+json, less, js и использовать их на уровнях layout и pages. Такой подход влечет за собой двойную работу по актуализации верстки и XLS-шаблонов.
На текущий момент хочется найти решение использовать полноту БЭМ исключительно в рамках UMI.CMS, а это соответственно использовать шаблонизатор BEMHTML в UMI.CMS, как это лучше сделать?
Технически, сейчас UMI.CMS рисует html в виде текста. Если вы сможете получить на выходе bemjson или другой json, вместо html, то появится возможность сделать прослойку между nginx и apache/php-fpm на nodejs, которая будет пробрасывать запросы от пользователя до umi.cms и на обратном пути, если это требуется, преобразовывать json/bemjson с помощью bemtree/bemhtml в html-строку на сервере. Если по простому — то нужно будет собрать 1 полный бандл (со всеми возможными блоками), и использовать собранные в нем bemhtml и bemtree технологии, если, скажем, выставлен заголовок, или какое-то другое ваше условие — решайте сами. Пример можете посмотреть, например, здесь: https://github.com/tadatu
Ну и появится возможность отрисовки на клиенте, про это есть куча информации, полноценный бэм-флоу.
UPD: Ну, либо, можно реализовать v8js биндинги, но это 1. pecl, 2. много дорабатывать, 3. медленно. Не фонтан решение.
Я привел в пример его bem-cocaine
Возможнсти такой реализации исследую, нашел такие материалы:
Если есть что то еще по этой теме, пишите, будет полезно.
HTML отдает шаблонизатор, без него от UMI.CMS можно получить xml/json через REST-протоколы, например через протокол UPage, пример: http://domain_fqdn/upage/page_url/.json
Грубо говоря json/bemjson в наличии, остается разобраться, где и что кешировать, и понять как будут разруливаться запросы от прослойки.
Реализация на express смотрится куда радужнее, чем v8js биндинги, а про cocaine cloud мало чего знаю, не заметил освещение этого сервиса.
Не не. cocaine cloud не нужен. Смотрите только строки с require bemtree и apply.
В принципе, можно через REST брать JSON, преобразовывать с помощью bemtree в bemjson, и отрисовывать через bemhtml уже в html.
Чтобы проксировать такой запрос нужно будет ручками проставить заголовки для UMI.CMS, будут разные нюансы с HTTP протоколом и данными в теле запроса, но по большому счету это мелочи.
express здесь не нужен, потому что он решает совершенно другую задачу. Его стоит использовать, если вам не нужна UMI.CMS в принципе. Я бы на вашем месте скорее смотрел в сторону http-node-proxy или даже своего решения.
Сам я планировал сделать некую универсальную, работающую из коробки прослойку для production, но пока руки не доходят довести до ума
Может быть дойдут руки написать список todo issues, прибавив к этому git и малыми совместнымии усилиями что то может получиться...
Если есть желание — начинал я это пилить тут https://github.com/zxqfox/bem-proxy
Но на ближайшую неделю-две у меня осталось часа 4
Вопрос, может быть глупый, но требующий ясности. Чем отличается или будет отличатся, пока еще неготовый для production, bem-proxy – Pure proxy server to render bemjson with bemhtml onto plain html and so on (BEM) от например node-http-proxy – A full-featured http proxy for node.js?
bem-proxy берет ответ от backend (json, bemjson, etc.) и сворачивать его в html по шаблонам из библиотеки блоков
node-http-proxy — это просто прокси, он просто запросы туда-суда кидает, как nginx
здесь поход за данными происходит прямо в bemtree-шаблонах, но это, конечно, опционально.
1. принимать запросы и роутить запросы
2. ходить за данными в UMI
3. преобразовывать json, полученный на предыдущем шаге в bemjson (либо просто с помощью обычных js-функций, либо используя bemtree-шаблоны)
4. преобразовывать полученный bemjson в html с помощью bemhtml и отправлять его пользователю.
Использовать node.js прослойку, может быть и меть свои плюсы, но конечного решения для продакшена не виджу и это надо еще тестировать и пилить.
Хочу обсудить отдельную ветку мысли. Как использовать бэм инструментарий в текущем окружении а это UMI.CMS + XSLT т.е. надо настроить bem-tools для работы с XSL-шаблонами, bem server для разработчика чтобы видеть что получается, в последствии получать результирующие XSL-шаблоны и объединенные CSS/JS/IMG блоков. Дополнительно, в идеале, возможность создавать автоматизированные тесты, генерировать доку и управлять релизами. Это возможно? Что для этого надо сделать?