Вопрос по BEMTREE и project-stub merged #1317
Comments
|
Вообще это странно. Я только что проделал эти же действия diff --git a/.enb/make.js b/.enb/make.js
index 8289757..e37b58b 100644
--- a/.enb/make.js
+++ b/.enb/make.js
@@ -25,7 +25,7 @@ var techs = {
browserJs: require('enb-js/techs/browser-js'),
// bemtree
- // bemtree: require('enb-bemxjst/techs/bemtree'),
+ bemtree: require('enb-bemxjst/techs/bemtree'),
// bemhtml
bemhtml: require('enb-bemxjst/techs/bemhtml'),
@@ -63,7 +63,7 @@ module.exports = function(config) {
}],
// bemtree
- // [techs.bemtree, { sourceSuffixes: ['bemtree', 'bemtree.js'] }],
+ [techs.bemtree, { sourceSuffixes: ['bemtree', 'bemtree.js'] }],
// bemhtml
[techs.bemhtml, {
@@ -109,6 +109,6 @@ module.exports = function(config) {
[techs.borschik, { source: '?.css', target: '?.min.css', minify: isProd }]
]);
- nodeConfig.addTargets([/* '?.bemtree.js', */ '?.html', '?.min.css', '?.min.js']);
+ nodeConfig.addTargets(['?.bemtree.js', '?.html', '?.min.css', '?.min.js']);
});
};и у меня вот такой результат: Но вообще, если нужно по BEMTREE генерировать статические HTML-страницы, то имеет смысл использовать https://github.com/tadatuta/bem-bemtree-static-project-stub (это примерно тот же project-stub + технология для генерации страничек с учетом BEMTREE). |
|
Попробовал на чистом test.bemtree.js block('test').content()(function(){
return {
tag: 'h1',
content: 'Hello!'
}
})Добавляю его в ...
block: 'header',
content: [
'header content goes here',
{ block: 'test' }
]
...В итоговом Или чего-то я ещё упустил? PS: bem-bemtree-static-project-stub уже ковырял, но не помогло |
|
У меня на
Ребята, может у вас там рабочий проект... и вся среда разработки закешировалось!? )))))))) А если без шуток. Пожалуйста дайте рабочий пример... не первый раз прошу - не ответили. С открытым сердцем, готов помочь - чем могу, хоть про |
Ну он как раз должен сгенерироваться с помощью bemtree. Вот тока не работает оно почему-то. |
Всё чудесатее и чудесатее. Вопрос - почему в Второй момент - Что-то тут видимо в Блин - сижу сверяю диффом make.js -ы. Бред какой-то. |
|
Ёёёёёперный театр - сколько же там магии и ручного кода. Заставил я это дело пинками работать, перетащив часть конструкций из ...
return BEMHTML.apply(BEMTREE.apply({ block: 'root' }));
...Т.е. как ты жопой ни крути, а корневым должен быть блок Ну и насколько я понял раз уж @tadatuta для |
|
@webhive Причина о том, что не бывает никакого «по умолчанию». Есть конкретные задачи и для них специфичные решения. Если говорить именно в контексте ENB, то с точки зрения сборки самого BEMTREE-бандла нет вообще ни малейших отличий от сборки BEMHTML. Отличия есть в источнике данных и в том, что именно хочется сгенерировать в результате. В частности, если нужно собирать по одной HTML-странице на основе BEMTREE, то не обязательно что-либо делать руками, можно просто брать https://github.com/tadatuta/bem-bemtree-static-project-stub, репозиторий для того и существует (блок Есть другая схема: когда на вход некоторая модель данных, а на выход произвольная структура HTML-страниц. Так, например, генерируется bem.info по вот такой модельке. Еще вариант — когда сайт динамический. Для такого подхода можно использовать репозиторий https://github.com/bem/bem-express. Все три варианта используют BEMTREE, но используют по-разному. Поэтому сделать что-то по-умолчанию и не получится. Ну и, наконец, не вижу ничего военного в том, чтобы написать под себя технологию для ENB. Если смотреть на https://github.com/tadatuta/bem-bemtree-static-project-stub/blob/master/.enb/techs/bemtree-to-html.js, то там менее двух десятков строк кода, остальное JSDoc. По смыслу там написано буквально следующее: возьми BEMTREE-бандл, передай в него данные, то, что получится передай в BEMHTML, а результат запиши на диск. В коде это еще проще, чем текстом: BEMHTML.apply(BEMTREE.apply({ block: 'root' }));Ну и оставшиеся вопросы:
Потому что технология получения HTML сама автоматически потребует сгенерировать BEMTREE-бандл. Указывать его в таргетах явно не обязательно (хотя и можно).
Тут может быть 2 причины:
Такая уж ли это прямо магия? ;) |
Ну как так-то? Там в качестве примера из коробки рисуется шапка с логотипом:
Возможно, проблема в том, что при создании собственных блоков они не указываются в депсах? В отличии от сборки по готовому BEMJSON-файлу, BEMTREE-шаблоны сначала необходимо собирать, поэтому депсы приходится писать руками (примеры там же рядом с bemtree-шаблонами). |
Не вполне соглашусь. В качестве примера сошлюсь на себя :-) Про сборку всё понятно - в смысле как оно работает, вернее даже как оно должно работать. Я немного про другое. Вот беру я bemjsonToHtml: require('./techs/bemtree-to-html')Названия не смущают? В обоих проектах вызывается [techs.bemjsonToHtml] но вот только внутренности разные. Это ли не магия?
На самом деле вот разница: В В общем как ни верти - много нюансов и неоднозначных мест. И простая казалось бы штука превращается в лютый геморрой. |
|
@webhive На самом-то деле при раскомментировании строк про сборку А вот дальше начинается кастомщина про то, как собиранный бандл использовать: собрать из каждого бандла отдельный HTML или одного бандла много разных, записать его на диск или отдавать на каждый запрос динамически и так далее.
Это скорее неудачный копипаст. Стоит поправить, с радостью приму pull request ;)
Прикол в том, что при желании эту схему можно сохранить и с BEMTREE. Например, использовать исходный bemjson-файл вместо захардкодженного в технологии блока Тут нет «правильного» решения, есть решения для конкретной задачи. |
|
С Вопрос в том:
|
|
@DjonyBastone проблема ещё актуальна? По поводу
// blocks/root/root.deps.js
[{
shouldDeps : [
{ block : 'page' }
]
}];Далее шаблонизатор попадает в блок // blocks/page/page.deps.js
[{
shouldDeps : [
{ block : 'header' },
{ block : 'main' },
{ block : 'footer' }
]
}];При попадании в // blocks/header/header.deps.js
[{
shouldDeps : [
{ block : 'logo' }
]
}];
По факту все зависимости можно указать в одном месте (например // blocks/root/root.deps.js
[{
shouldDeps : [
{ block : 'page' },
{ block : 'header' },
{ block : 'main' },
{ block : 'footer' },
{ block : 'logo' }
]
}]; |
|
По поводу построения нужных страниц, @tadatuta а действительно... Как генерировать нужные страницы? Раз Тут что-то странное. |
|
@belozer И так как ответа нет, и сам не сообразил - то, забросил это дело, всю разработку по бэм. Вопрос вообще важный, влияющий на принятие решения об архитектуре проекта. И очень жаль что ребята игнорируют данную тему. |
|
@DjonyBastone архитектурно нет ничего сложного :) Просто из коробки решения не самые удачные для старта, к сожалению... Проблема в том, что они часто запутывают или ведут в тупик (как project-stub). На следующих выходных постараюсь собрать стартовый набор для разработки (с выжимкой граблей, которые отгрёб за время изучения). Надеюсь он тебе поможет :) |
|
Это очень хорошая идея!!! Если что смогу помочь с документацией, вдруг потребуется. Есть опыт - доходчиво оформлять инструкции, минирегламенты, руководства |
Блин, в том-то и загвоздка - архитектурно всё отлично и даже заманчиво, но реализация- жуть и мрак. Всё время уходит на борьбу с бэм-ом, а не на разработку.
Я вот уже несколько раз забрасываю, потом опять - дай думаю попробую - опять шаг вперёд и снова как в болото то одно не работает то другое и опять рукой махну. |
|
@webhive @DjonyBastone Накидал "своё видение" стартового набора для обучения бэм разработке. https://github.com/bem-contrib/bem-starter-kit Он во многом похож на репозиторий @tadatuta, практически идентичен. Из плюсов данного подхода:
Из минусов:
Как выглядит flow:Шаг 1.Создаётся бандл/страница В общем на этом этапе сохраняется простота project-stub. Всё что объявлено в этом Шаг 2.Чтобы не городить длинные полотна из В общем как-то так. Всё просто.
Технические/промежуточные бандлы типа декларций я постарался отделить точкой в начале имени файла, чтобы они прятались системой от глаз. Так выглядит собранный бандл (без промежуточных файлов) П.Н. Пробуйте :) Получается или нет в такой схеме вам работать. Буду ждать отзывов, т.к. буду его дорабатывать время от времени. |
|
Я конечно дико извиняюсь, но действительно в чём тут принципиально отличие от Сделайте внятный пример с как минимум 2-мя разными бандлами, где будет допустим общий header/footer, но разный контент.
Опять у нас bemjson "first-class citizen" на входе у нас данные, а bemjsоn надо ещё сгенерировать. Давайте уж перейдём к реальным примерам из реальной жизни, а не абстрактным вещам "берём bemjson и он прекрасно превращается в html". У меня нет сомнений, что обе технологии bemhtml и bemtree работают (это суть одно и то-же). Вопрос как их применять на практике в реальных задачах. Чтоб подлить масла в огонь подкину идею - теперь выложите проект на сервер и чтоб там оно работало и на реальные запросы отвечало в динамике. Не просто сгенерированный html отдавать как статику, а чтоб весь цикл отрабатывал data -> bemtree -> bemhtml -> html. Насколько я понял придётся писать свою middleware и внутри вызывать bemtree и bemhtml из библиотеки, а не пользоваться сборщиком. И вот там ещё больше ада, хотя опять на одной простой страничке с одним блоком всё вроде бы и нормально, но шаг влево шаг вправо и начинаются проблемы. Итого прорезюмирую - такие примитивные примеры как у вас смысла не имеют. Времена когда для демонстрации хватало вывести "Hello world!" уже давно прошли. Сделайте реальный пример на полном стэке -- |
|
@webhive спасибо за отзыв. Не всё совсем так, как ты описал. Этот кит немного хитрей и больше представляет собой "статический" набор для вёрстки, которую потом намного проще подключить к динамике.
На сервер выкладывать не буду, а вот функцию для рендера данных добавлю. |
|
@belozer Еще не ознакомился, на неделе обкатывать буду. Будут вопросы обязательно напишу! По документации параллельно прилагать усилия? |
Поставил project-stub из merged ветки.
В нём есть 3 места где закомментировано использование bemtree. Соответственно раскомментировал, но bemtree-файлы почему-то не подхватываются.
Даже упоминания нет. Соответственно вопрос - что делать?
The text was updated successfully, but these errors were encountered: