На моем проекте так принял:

block : 'page',
сontent : [
    {
            block : 'dropdown-layout'       /*выпадающее меню, вынесено отдельно для реализации свайп-меню snap.js*/
    },
    {
            elem : 'content',
            attrs : { id : 'page__content'}, /*видимый контент страницы*/
            content : [
                {
                    block : 'header',
                },
                {
                    block : 'content',  /*меняющийся контент разных страниц*/
                },
                {
                    block : 'footer',
                }
            ]
    }
]

.page__content и .content - не пересекаются. больше всего мне понравилось то, что можно менять содержимое любого блока (хедер, футер, любой другой блок). Контент указан в bemjson своей страницы, а шаблонизатор пройдет по bemjson применит описанные шаблоны блоков bemhtml - на выходе получится только то что надо.

Это один бандл? Т.е. для каждого нового бандла (типа страницы) нам надо вот эту структуру копипастить? И не понял как это "Контент указан в bemjson своей страницы" у нас ведь bemjson один на весь бандл. У блоков же нет bemjson-а, только bemhtml.

Ну и сходу ещё проблема. Допустим надо мне в этот bemjson подсунуть данные через bemtree. И надо мне сматчиться на какой-то блок внутри блока content. Как быть? Не на что матчиться-то. Т.е. чтобы bemtree применить надо чтоб блок был d bemjson-е.

Или у вас вообще где-то отдельно ещё генерится html (bemtree -> bemjson->bemhtml) но без page, а потом в виде контента уже подставляется в вот в этот bemjson в блок content? Т.е. типа 2 прохода получается?

У меня только статика, шаблонизация проходит на этапе сборки бандлов. Одна страница - один бандл.

Про bemtree не знаю, стэк использую только для разработки. Вроде так : bemjson->bemhtml->html. Весь смысл то и заключается - накидать блоки в bemjson, по максимуму написать шаблоны bemhtml, и наслаждаться сборкой)) А копипастить не вижу проблемы - накидал один бандл, сохранил под неведомым названием в буфер куда-нибудь, вот и заготовочка, пиши свой контент сколько хочешь.

Можно посмотреть граф сборки по адресу http://localhost:8080, если используется ENB server.

это моё видение - субъективное, у ребят с опытом может есть еще чем поделиться. Я пока 3 месяца в этой каше варюсь, но полезность методологии уже почувствовал.

Нее - так не катит. Так и я умею :) Собственно интересовало именно как всё это сделать на полном стэке.

Я пока 3 месяца в этой каше варюсь, но полезность методологии уже почувствовал.

Да я вот тоже - методология нравится - для вёрстки уже приноровился использовать, т.к. это действительно удобно, а весь стэк .... мне кажется че-то с ним не то. Слишком много граблей :)

Отвечу сам себе :)

Как оказалось bemjson как таковой и не нужен и как ни странно правильный именно мой второй вариант. Собственно суть драмы вот тут https://github.com/bem/project-stub/issues/159

Вроде судя по описанию (оригинальная документация), чтоб задействовать bemtree у нас должен быть bemjson (иначе куда матчиться?), а в то-же время оказалось, что bemjson как таковой и не нужен - он вырождается в один единственный корневой элемент, на который потом bemtree навешивает всё остальное.

И теперь опять в который уже раз встают вопросы адекватности документации процессу разработки. Почему столько внимания в документации именно bemjson-у? Почему во всех уроках и туториалах - "вот например возьмём такой-то bemjson"? Bemjson получается несколько вторичен.

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

)))) В поддержку темы:

Существует header с многоуровневым меню.

1. Как сделать его декларацию в бандле просто - {block: 'header'} ? Что бы все внутренности блока, его требуха (элементы, внутренние блоки) - появились в результате.
2. Как сделать так, что бы при изменении внутреннего устройства header не приходилось в каждом бандле *.bemjson.js ходить и редактировать код?
3. Если bemhtml не поддерживает вложенности, как организовать header с многоуровневым меню ? Писать разные псевдо-бэм типа - header__menu-list_lvl_2, header__menu-item_lvl_2, lvl_1-118+ !? :D
4. В каких технологиях необходимо проектировать? что бы получить желаемый результат - Если нужно добавить ссылку в списке меню на 3м уровне. Я просто смог пойти в один шаблон, внести изменения в одном месте, и добавилось изменение на всем проекте.

Хотелось бы изначально понимать какую структуру методов будем использовать, для получения цели - быстрые изменения на всем проекте. Согласен - знаний немного по методологии и js (прошу не пинать), но мыслить структурами и методами - научен.

P.S. bemjson небольшой странички уже 2001 строк. Мне страшно продолжать проектировать странички в bemjson, от мысли - "а если добавить ссылочку в меню хедера!?"

В том-то и дело, что как оказалось bemjson не нужен. Весь bemjson должен состоять из одного блока - ну пусть это будет { block: 'root' }. Всё!!! Вот такая блин фигня. Далее bemtree блока root

block('root')(
  content()(function () {
      return [
        { block: 'header' }
      ];
  })
);

Вот так, а не иначе должен ваш header появится в bemjson. Ну или не обязательно header - можно натолкать туда любую структуру. Потом каждый компонент в своём bemtree файле в себя напихивает свои вложенные куски bemjson-а и т. д.

Т.е. отвечая на вопросы 1 и 2. Bemtree для вашего header-а.

block('header')(
  content()(function () {
      return [
        { block: 'header', elem: 'menu-list' },
... ну и далее всё, что вы писали в bemjson-е на уровне ниже header-а 
(все остальные блоки) переносите сюда
      ];
  })
);

Теперь не надо бегать по bemjson-ам т.к. их нет. Ковырять надо bemtree файлы.

Если bemhtml не поддерживает вложенности, как организовать header с многоуровневым меню ?

Вот как раз дело-то в том и есть, что bemjson генерируется, а не создаётся руками. Тогда в bemtree вы и натолкаете в bemjson всю структуру меню.

Bemtree это как bemhtml но только bemhtml создает из bemjson-а html, а bemtree из кастрированного (вырожденного) bemjson-а (фактически болванки из одного элемента) нормальную полновесную структуру.

В каких технологиях необходимо проектировать?

Надеюсь сейчас всё стало понятно? Тут дело не в ваших знаниях - документация просто ужасна. Она совершенно не отражает работу, только отдельные аспекты. Всю информацию приходится собирать по крупицам из форума.

bemjson небольшой странички уже 2001 строк. Мне страшно продолжать проектировать странички в bemjson, от мысли - "а если добавить ссылочку в меню хедера!?"

Я собственно тему создал по той-же причине. Создал главную страничку, потом пришло время сделать ещё одну и тут я понял, что что-то пошло не то. Новый bemjson создавать который будет на 95% таким-же (а потом всё это поддерживать) вообще не вариант.

В форуме так и никто не ответил, да и я параллельно рыл информацию и наконец нарыл. Ключевой момент всей истории - bemjson руками не создаётся. Блин - об этом должно быть написано красными жирными буквами вдоль всей документации :)

Вы сходите кстати по ссылке https://github.com/bem/project-stub/issues/159 - там много интересного по теме.

Спасибо))

Да, я уже перечитал, прежде чем написать предыдущий ответ на пост. Что и натолкнуло на мысли, о самом неприятном. В том иссуе - обсуждение полугодичной давности (если не больше). Если bemtree - значит bemtree, лишь бы работало!

Хотелось бы узнать - что команда БЭМ сейчас думает по этому поводу!? Хотя бы справочно. С документацией согласен - печально. Если бы занимался веб-разработкой боле-менее профессионально, может было бы попроще... понимать эту документацию.

А в общем Спасибо ребята за методологию!! Хорошо что не за бугром придумали, а то пришлось бы со шведского языка переводить документацию :D

Еще рекомендую к прочтению по теме: https://ru.bem.info/forum/716/

Вопрос - почему эта информация отсутствует в документации? Повторюсь в который уже раз (и видимо не только у меня такое мнение) - документация стимулирует делать неправильно. Ну скажем так - условно неправильно, т.к. критерии правильности тут разные. Вот опять доходишь до какого-то уровня и понимаешь, что всё что сделано надо переделывать (в частности надо разбивать bemjson, на который и так убита куча времени на bemhtml-ы)

Мыши плакали, кололись, но продолжали есть кактус

@webhive ответ простой: документация в том виде, в котором у нас хватает сил ее писать. будем очень рады любой помощи в этом деле.

@tadatuta Хочу обратить ваше внимание на то, что даже вы рекомендуете почитать ветку форума, а не раздел в официальной документации. Это как бы намекает нам о том, что вы и сами свою доку не воспринимаете как источник информации.

Почему кстати эти бесценные ветки форума (или issues guthub-a), которые передаются как некое сакральное знание из уст в уста отсутствуют в официальной документации? Ведь в них пользы гораздо больше, а спрятаны они очень далеко. Шерстить форум в поисках информации крайне неблагодарное занятие. Хоть ссылки какие-то сделайте что-ли на нужные ветки. Это-то ведь думаю не требует экстра усилий.

Я кстати пытаюсь статью написать по этой теме (уже полгода как :)), но т.к. я параллельно проверяю всё о чём пишу, то каждый раз упираюсь в какую -проблему. Сейчас (в очередной раз) у меня очередное просветление - думаю продолжить и собрать таки где-то в одном месте доку как это всё работает на самом деле.

Это как бы намекает нам о том, что вы и сами свою доку не воспринимаете как источник информации

Это намекает лишь на то, что информация из ветки форума пока не попала в документацию ;)

Почему кстати эти бесценные ветки форума (или issues guthub-a), которые передаются как некое сакральное знание из уст в уста отсутствуют в официальной документации?

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

Я кстати пытаюсь статью написать по этой теме (уже полгода как :))

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

думаю продолжить и собрать таки где-то в одном месте доку как это всё работает на самом деле

Это чудесно! Буду рад помочь с вычиткой.