cc @zxqfox

У ZF много своих тонкостей, и я в нем не особо разбираюсь и не пробовал в него встраивать bh-php. Попробую поотвечать или позадавать наводящих вопросов.

передача данных в block.bh.php Не всегда можно запросить данные непосредственно из файла, если на странице вызваются несколько блоков, например функция, выполнится дважды $dataMenu = GetData('menu')

чем плохо?

$menudata = GetData('menu');
$bh->apply([
  [ 'block' => 'my-menu', 'data' => $menudata ],
  [ 'block' => 'my-menu', 'mods' => ['with-modifier' => true], 'data' => $menudata ]
]);

упс.)

Древо view zend обрабатывает view на страницы по своему (своя структура и свое древо) и страницы собираются через контрроллер, бэм предлагает на каждую страницу, свой бандл.

как вариант, в зенде генерировать bemjson дерево в первый проход, а после получать html с помощью $bh->apply(дерево с готовыми данными).

Кеширование Проблемы с кешированием (memcache, sphinx, инстанс самого зенда)

Разберемся что у нас есть:

• сырые данные (база, сфинкс, старые абстрактные кеши)
• алгоритмы построения bemjson (часто, не чистые функции)
• алгоритмы преобразования bemjson в html (bh-php, для кеширования должны быть чистыми, не использовать окружение, использовать только входные параметры);

Что мы можем кешировать? Если функции чистые (не учитывают окружения) то мы можем гарантированно сказать, что если не менялся исходник (некие входные в алгоритм данные), то не поменяется и результат. Это значит, что нам нужно просто определиться с вектором параметров кеширования (например, посмотрите *_cache_key в nginx): минимальным набором параметров, от изменения которых меняется результат. В этом случае, проблем с инвалидацией кеша не будет и можно безболезненно им пользоваться, сбрасывая в нужное время.

Сборка одной страницы для двух пользователей Сейчас результатом работы БЭМ является html страница, которая генерируется порядка 150ms, а с кеша выдается за 30ms Если есть главная страница, в ней допустим блок "username", то для каждого пользователя нужно держать в кеше готовую страницу, а если он авторизуется, то тратить 150ms на создание новыой страницы

Если хочется делать это именно на php — можно при отрисовке общего хтмл оставлять какую-то разметку, в которую позже вставлять пользовательские данные. Тогда у вас будет 30ms + какое-то время на отрисовку блоков с пользовательскими данными: `$bh->apply(['block' => 'user-related-block', 'data' => ... ]]);

Мы у себя решили, что нет смысла нагружать пхп такими вещами и догружаем их jsом из веб-сервисов на go, ruby, nodejs. Таким образом у нас возможен кеш вообще всей страницы и делаем мы его обычно на nginx — это даже не 30мс.

Добавляем на страницу несколько переменных вида "фильтр товаров", "вид отображения товаров", "страница пагинации" и имеем бесчисленное множество html.

Выше ответил про вектор параметров кеширования, не уверен, что знаю как это по-русски звучит.

Как правильно хранить кеш в таких случаях?

Можно, конечно, и отдельные блоки кешировать, А после либо str_replace($result, '%CACHEDBLOCK%', $cachedBlock) по размеченному кешу страницы, либо [ 'content' => $cachedBlock ] при рендере страницы целиком ($bh->apply).

Как быть если в html кеш попадут конфиденциальные данные?

При отрисовке блоков с конфиденциальной информацией выставлять заголовок «не кешироваемое» и не будет проблем. Не может быть, чтобы зенд не позволял это сделать.

Если ответил на что-то не то — переспросите, пожалуйста)

@zxqfox Спасибо! Будем пробовать разбираться. Нам для front-enda БЭМ дает много приемуществ и устраняет множество проблем, а в плане взаимодействия с back-end тут пока больше вопросов.

@PAND-or а вариант с nodejs не рассматривается? А что будет с вашими наработками если завтра вдруг придет другой бекендер и скажет "давайте ruby"?

@voischev интересное замечание! Как тогда полностью отделить фронтэнд от бэкенда? делать дополнительную прослойку для передачи данных? php -> node ?

Если вариант с nodejs — то вообще не понятно зачем там php ;-)

Но если очень нужно, то можно в php оставить что-то самодостаточное, например, только некоторое API (скажем, REST) и логику моделей, а в ноде вытягивать нужные модельки не из базы, а из пхп, и формировать странички (bemtree+bemhtml/bh).

И будет nginx (с кешом для анонимов) → nodejs (с точечным кешом) → php (с кешом бд ;-).

Мы в студии Мануфактура пережили с php+Zend, RoR, php+Laravel, + разные подрядчики. Во всех случаях у нас был стабильный пуле-непробиваемый фронтенд :). Плюс простые сайты/зачачи мы решали полностью на Node.js cтеке. Бек во всех случаях готовит JSON и нам не важно с какой платформы он пришел)))

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

nginx (с кешом для анонимов) → php (любой сервер с кешом бд и тд ;-) → nodejs (тупо функция для шаблонизации JSON To HTML которая его плюет обратно в "большой" сервер).

Но вариант описанный @zxqfox конечно мне больше нравится. Но там и распределение задач сильно другое.

отмечу, что такой вариант не стоит никогда использовать при хайлоаде), потому что пхп синхронный, а nodejs будет простаивать большую часть времени)

@zxqfox +1 Но раз у ребят уже пхп то скорее всего этот вариант ребятам с бекенда будет сильно понятнее и привычнее. И для фронтендера так же не потребует дополнительных знаний по работе с серверами.

// cc @zxqfox Ты мог бы поделиться логикой построения страниц на PHP с использованием BH ? "Рабочие практики".

Как и в каком месте лучше строить дерево и как строить его для разных страниц.

В голове пока создание блока page и пробрасывание в него данных. А страницы являлись бы модификаторами со своим набором блоков.

Блок page выступал бы в роли "bemtree"

@belozyorcev У нас примерно так и работает. Модификаторы на page и пара крупных блоков вроде header, footer по сути выполняют роль bemtree. В $json->data передаем им кусок исходных данных а они уже генерируют подробный bemjson.

@kompolom А шаблонизацию на клиенте делаете средствами bh-php (данные клиента->сервер->готовый html) или клиентский JS bh/bemhtml?

upd. И ещё один вопрос. Зависимости для сборки как формируете? Через bemjson?

@belozyorcev зависимости в модификаторах page. Ну и каждый "мелкий" блок знает про свои зависимости. На публичной части с сервера приходит готовый html. В админке в некоторые блоки даем json который потом рендерится.

@belozyorcev если прям сильно жмет js, то лучше писать шаблоны в двух вариантах + шаблоны на генерацию bemjson отдельно.

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

bemjson-шаблоны (через $bh->processBemjson как аналог bemtree) — можно посложнее, и на одном php. Их же можно тестами покрывать отдельно, если жмет.

Либо же, nodejs перед php можно поставить и все это делать там, и все шаблоны писать на js — надо только рассказать начальству, что даже wordpress уже на ноду переписали.

@zxqfox @kompolom прошу прощения за размытость вопроса. Я имел в виду собирку бандлов.

У меня всё ещё нет чёткого понимания как совмещать nodejs + php. Из-за недостатка опыта наверное или готовых примеров. Вот и копаю туда "что понимаю". Хотя реализация шаблонов на ноде больше привлекает.

@belozyorcev в бандлах указываем тот самый модификатор на page - все поддтягивается. Например:

 ({
   block : 'page',
   mods : { blog : 'post' },
  .....
})

А зависимости уже описаны в page_blog_post.deps.js

Бандлы через bemdecl делаете или через bemjson -> bemdecl?

Через bemjson. Есть проект в котором только bemdecl, но мне не особо нравится. Писанины примерно столько же, а лично мне приятней в bemjson.