Open alexanderbondarchuk opened 8 years ago
@alexanderbondarchuk Привет!
Спасибо за терпение и желание со всем разобраться. Технологий действительно много, а связка с PHP особенно неочевидна, т.к. почти не описана в документации.
Я бы предложил поступить так: разобраться с «основной» частью на основе node.js. Исхожу из того, что JS для любого фронтэнд-разработчика знаком и освоение ноды и npm не будет слишком сложным благодаря большому количество туториалов всех видов.
Для общего понимания того, как работает сборка, я бы порекомендовал методологическое описание https://ru.bem.info/method/build/ + https://ru.bem.info/method/declarations/ — здесь буквально на 10 минут чтения и объясняются именно принципы, без какой-то привязке к конкретным сборщика и инструментам.
А следующим шагом посмотреть вот это видео: https://www.youtube.com/watch?v=-un-YYgU6Pg Там (как мне кажется) сборка объяснена более-менее внятно.
И уже после такого знакомства погружаться в связку с PHP.
@tadatuta спасибо за ссылки, ознакомлюсь на неделе.
@alexanderbondarchuk Если по сути, то сборщик не нашел файл desktop.bundles/firstpage/firstpage.bemjson.js
а именно в нем должна быть описана структура страницы.
@tadatuta, эти вещи действительно уже читал, но они начали вылетать из головы, когда начал пытаться адаптировать прочитанное для PHP. Повторение информации оказалось полезным для меня.
Видео пока не смотрел, но по прочитанному очень абстрактно и без конкретики описаны несколько вещей:
В результате сборки можно получить разные финальные наборы файлов
- далее говорится что наборы файлов могут быть как для отдельной страницы, так для куска страницы или для шапки и подвала. БЭМ сам определяет что шапка, что кусок, а что целиковая страница? Так же, если не ошибаюсь, в пачки попадают и ненужные на сервере файлы, промежуточные - но об этом ничего тут не сказано. Или я ошибаюсь?При сборке в проект могут быть включены все БЭМ-сущности с файловой системы/только необходимые для построения страницы БЭМ-сущности
- и далее идёт уточнение, что чтобы включать только нужное, надо использовать декларации, зависимости и уровни переопределения. В примерах файловой системы бэм-проекта ДО сборки файл decl уже лежит в пачке, однако если читать материал про зависимости - там сказано, что кроме ручной подготовки такого файла есть ещё 2 автоматических способа, например При сборке страницы декларация формируется автоматически на основании данных из БЭМ-дерева
. При этом вроде используется инструмент html2bemjson. Что-то здесь совсем не понятно - с одной стороны нам обязательно надо готовить заранее decl файл, с другой нам говорят что при сборке (enb make, верно?) этот decl файл сам соберётся.Кстати, есть ошибка на странице https://ru.bem.info/method/build/ не работают якоря для ссылок
перечислить блоки, элементы и модификаторы, участвующие в построении страницы указать зависимости используемых БЭМ-сущностей
БЭМ сам определяет что шапка, что кусок, а что целиковая страница?
Нет, с точки зрения сборки это просто не важно. Управляется это списком сущностей, которые попали в декларацию.
Так же, если не ошибаюсь, в пачки попадают и ненужные на сервере файлы.
Да, но не так-то просто однозначно понять, какие файлы нужны, а какие нет, поэтому чистка лишнего отдается на откуп разработчику. Должно хватить однострочника типа rm *bundles/*/*.{decl.js,deps.js}
с необходимыми расширениями.
с одной стороны нам обязательно надо готовить заранее decl файл, с другой нам говорят что при сборке (enb make, верно?) этот decl файл сам соберётся.
Не совсем так. Список сущностей, которые должны попасть в бандл при сборке, обязан быть предоставлен в каком-либо виде: можно написать его руками в виде decl-а, можно написать руками BEMJSON или любой другой формат, из которого этот decl можно сгенерировать.
Но важно понимать, что при динамической генерации страницы дерева заранее нет и распространенная практика выглядит так: в decl указывается один корневой блок root
, а все остальные зависимости строятся по блочным deps.js
-файлам.
Очень заинтересовала алгебра деклараций, но почему-то нет практического примера с ними
Мы сознательно в разделе Методология не приводим никаких готовых примеров. Работа с декларациями реализована, например, в ENB: https://ru.bem.info/tools/bem/enb-bem-techs/api/#mergebemdecl (и ниже по тексту).
Кстати, есть ошибка на странице https://ru.bem.info/method/build/ не работают якоря для ссылок
перечислить блоки, элементы и модификаторы, участвующие в построении страницы указать зависимости используемых БЭМ-сущностей
@vithar посмотришь на якоря?
Да
@tadatuta Владимир, видео посмотрел. Всё понятно, очень жаль только что про decl и deps пару слов сказано.
Вы пишете
при динамической генерации страницы дерева заранее нет и распространенная практика выглядит так: в decl указывается один корневой блок root, а все остальные зависимости строятся по блочным deps.js-файлам
Допустим я придумал себе блок hardlabel
, который хочу подключить на страницу.
Мои действия
exports.blocks = [
{ name: 'hardlabel' }
];
Т.е. при сборке enb make поймёт, что я хочу подтянуть css и js по блоку hardlabel? В данном случае hardlabel и есть корневой блок о котором вы говорите? Или под корневым имеется в виду i-bem блок?
Не совсем понял роль deps... Т.е. кроме того что мы в decl сказали подтянуть нам css и js файлы блока hardlabel, нам надо в hardlabel.deps.js указать что-то вроде этого?
{
tech: 'js',
mustDeps: [
{
block: 'hardlabel',
tech: 'bemhtml'
}
]
}
Т.е. при сборке enb make поймёт, что я хочу подтянуть css и js по блоку hardlabel?
Да.
В данном случае hardlabel и есть корневой блок о котором вы говорите? Или под корневым имеется в виду i-bem блок?
Формулировка вопроса позволяет разночтения, поэтому отвечаю развернуто. Заодно и на следующий вопрос отвечу.
«Корневой» — в терминах графа зависимостей, аналог точки входа для Webpack.
Например, таким блоком может быть page
. А дальше у блока page
в файле deps.js
могут оказаться header
, main
, sidebar
и footer
. У header
, в свою очередь, будет зависимость от logo
. У sidebar
— от link
. У footer
— от copyright
. И так далее.
В результате сборщик принимает на вход декл с page
и достраивает весь граф зависимостей с помощью зависимостей, указанных в блочных deps.js файлах.
Пример в коде: https://github.com/tadatuta/bem-express/tree/master/common.blocks (см. root
и далее по deps.js в common.blocks
).
Вместо этого, конечно, можно написать весь список зависимостей в декле, но схема с блочными deps.js-файлами лучше тем, что каждый блок сам отвечает за свои зависимости. Т.о., например, при удалении какого-либо блока, автоматически исключаются все его зависимости.
@tadatuta Владимир, доброго времени суток. Нечто невероятно функциональное удалось сотворить, значит инструкции по теории + видео оказались полезными и думаю в будущем могут помочь не только мне.
Следующим шагом мне бы хотелось реализовать то же самое, но в связке с PHP. 1) Какую информацию почитать для этого? 2) В чём разница между bh, bemhtml, bemjson и что из этого предпочтительнее использовать при разработке с помощью PHP? 3) Правильно ли я понял про корневые элементы, что под корневым имеется в виду самый дочерний блок (который мы и указываем в decl), а с помощью deps лежащих в *.blocks от этого дочернего блока строятся все остальные связи, которые в целом могут не беспокоить разработчика?
Следующим шагом мне бы хотелось реализовать то же самое, но в связке с PHP. 1) Какую информацию почитать для этого?
Зависит от схемы, по которой хочется делать эту связку: какие требования, чего хочется достить в результате?
2) В чём разница между bh, bemhtml, bemjson и что из этого предпочтительнее использовать при разработке с помощью PHP?
BEMJSON
— это формат описания дерева страницы в терминах блоков.
Было
<div class="b1">
<div class="b1__elem1"></div>
</div>
Стало
{
block: 'b1',
content: { elem: 'elem1' }
}
Подробнее см. https://ru.bem.info/technology/bemjson/
А BEMHTML
и BH
— это два шаблонизатора, которые на вход принимают BEMJSON
и возвращают HTML
. Разница в синтаксисе и некоторых тонкостях в реализации.
Если говорить про PHP, то существует порт BH
на PHP
— https://github.com/bem/bh-php + в комплекте есть шаблоны для блоков из библиотек bem-core
и bem-components
.
3) Правильно ли я понял про корневые элементы, что под корневым имеется в виду самый дочерний блок (который мы и указываем в decl), а с помощью deps лежащих в *.blocks от этого дочернего блока строятся все остальные связи, которые в целом могут не беспокоить разработчика?
Да, все так.
@tadatuta
Зависит от схемы, по которой хочется делать эту связку: какие требования, чего хочется достить в результате?
Для начала хотелось бы понять что меняется в процессе сборки проекта enb make, когда в нём появляются php файлы, кладутся ли они в другие директории или по прежнему в bundles
?
Про bh-php знаю, устанавливал и немного баловался. Не понятно может ли enb make работать с bh-php
?
Если верно понимаю, то раз bh-php
это шаблонизатор то код страницы по прежнему можно писать в отдельном bemjson
файле, даже если я хочу работать с проектом на php
.
Можно ли в php
использовать bemhtml
и что между ним и bh-php
будет удобнее в работе?
Высока вероятность, что bemhtml
будет более современной и актуальной, чем bh-php
, потому что в первую очередь методология БЭМ дружит с javascript и node.js, а потом уже делаются доработки для других языков?
Про bh-php знаю, устанавливал и немного баловался. Не понятно может ли enb make работать с bh-php?
enb-bh-php
собирает bh.php
точно так же, как и enb-bh
собирает bh
.
После сборки надо будет подключать себе файлы с шаблонами и делать $bh->apply(['block' => 'page'])
.
Если верно понимаю, то раз bh-php это шаблонизатор то код страницы по прежнему можно писать в отдельном bemjson файле, даже если я хочу работать с проектом на php.
Всё так. Можно, но не обязательно нужно. В любом случае, нужна будет какая-то точка отсчета для сборки бандлов — это либо bemjson (из которого можно получить список используемых бэм-сущностей) либо bemdecl (голая декларация из кусков бэм-сущностей).
Можно ли в php использовать bemhtml и что между ним и bh-php будет удобнее в работе?
Технически, можно, но это не эффективно, поскольку bemhtml написан на js, и запускаться в php может только через адаптеры (например, биндинги v8). Но если есть возможность поднять nodejs-прокси, который будет делать ровно рендеринг html из bemjson используя bemhtml, то лучше сделать именно так, а из php отдавать json_encode(bemjson-структура)
.
Высока вероятность, что bemhtml будет более современной и актуальной, чем bh-php
Тут даже вероятность не нужно считать — она ровно 100. Но запускать bemhtml из php практически невозможно и поэтому есть bh-php (кроме того, он появился еще когда у bemhtml были не самые лучшие времена, но это другая история).
методология БЭМ дружит с javascript и node.js, а потом уже делаются доработки для других языков?
Сама методология в первую очередь методология, поэтому ей без разницы с кем дружить и она просто ни с кем не ссорится. Но есть браузерные разработчики, которые интересуются BEM, и знают они именно JS, поскольку он используется в браузере — это и есть главная причина, почему 99.99% всего написано на JS.
Ну и доработки, в общем-то, делаются силами сочуствующих и нуждающихся — своими руками, можно сказать. Поэтому, если нет возможности использовать nodejs и есть желание портировать bemhtml на php — я могу даже рассказать как это в теории можно сделать малой кровью, но стоит помнить, что надо будет поддерживать эту штуку, потому что нового ничего само не появится, и если были какие-то баги — придется их периодически перепортировать.
Для начала хотелось бы понять что меняется в процессе сборки проекта enb make, когда в нём появляются php файлы, кладутся ли они в другие директории или по прежнему в bundles?
По прежнему в .bundles, просто собираются немножко иначе — обертка в другом синтаксисе, и <?php
в начало добавляется ;-).
@tadatuta @zxqfox Всем привет.
Такс, если речь пошла про enb-bh-php
, то логично это это ещё какая-то технология, которая должна быть установлена. Я не знал как проверить есть она или нет в моём стандартном project-stub, поэтому просто выполнил согласно инструкции команду npm install --save-dev enb-bh-php
, выдало следующее
bem-project-stub@1.5.0 /home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex
└── enb-bh-php@0.1.4
Честно говоря даже после выполнения этой команды не удалось понять что и куда добавилось. Т.е. сделав это я могу быть уверен, что все инструменты для сборки PHP проектов у меня есть?
Едем дальше. Про подключение файлов с шаблонами вообще ничего не понял. Вот есть у меня страничка htmlpage
, в ней лежат htmlpage.bemjson.js
и htmlpage.decl.js
, которые после команды enb make
"делают хорошо". Шаблоном в данном случае является, если не ошибаюсь htmlpage.bemjson.js
. Не совсем понял как связать этот шаблон и команду $bh->apply(['block' => 'page'])
- наверное всё-таки в скобках этой команды должно попадать полное содержимое из файла htmlpage.bemjson.js
?
После сборки надо будет подключать себе файлы с шаблонами и делать $bh->apply(['block' => 'page']).
Для успешной сборки html+css+javascript мне в пачке htmlpage
хватило двух файлов htmlpage.bemjson.js
и htmlpage.decl.js
. Если верно понимаю, для PHP будет нужно что-то ещё. В какую сторону смотреть, если для начала я просто хочу реализовать абсолютно то же самое что реализовал выше, но с помощью PHP?
после выполнения этой команды не удалось понять что и куда добавилось. Т.е. сделав это я могу быть уверен, что все инструменты для сборки PHP проектов у меня есть?
Тут требуются общие базовые знания работы с node.js
. Мы их не осилить давать в нашей документации, но есть огромное количество обучающих материалов именно про ноду и npm
.
Могу порекомендовать скринкасты http://learn.javascript.ru/screencast/nodejs
Шаблоном в данном случае является, если не ошибаюсь htmlpage.bemjson.js
Как я и писал выше, BEMJSON
— это описание страницы в терминах блоков. А за то, как это описание превратится в HTML отвечают шаблоны. Т.е. htmlpage.bemjson.js
следует воспринимать скорее как данные (правда уже view-ориентированные).
Шаблоны по аналогии с тем, как CSS стили применяются к узлам дерева HTML, применяются к узлам дерева BEMJSON и задают правила их рендеринга. И, как и с CSS, существуются правила по умолчанию, которые отрендерят любой узел в div
с необходимым классом, даже если вообще не писать никаких шаблонов. Сами шаблоны (снова-таки по аналогии с CSS) лежат рядом с каждым блоком в отдельном файле и представляют из себя утверждения вида «найди в дереве узел, отвечающий селектору и пусть тег у подходящих узлов будет span
».
как связать этот шаблон и команду
$bh->apply(['block' => 'page'])
- наверное всё-таки в скобках этой команды должно попадать полное содержимое из файлаhtmlpage.bemjson.js
?
После сборки в $bh
будет объект с методом apply
, содержащий знание про все шаблоны нужного бандла. Аргументом apply
как раз и должен быть BEMJSON
: $bh->apply($bemjsonFromHtmlPage)
.
Для успешной сборки html+css+javascript мне в пачке htmlpage хватило двух файлов
htmlpage.bemjson.js
иhtmlpage.decl.js
.
Если стартовал с project-stub
, то должно быть достаточно одного htmlpage.bemjson.js
, декл генерируется на его основе.
В какую сторону смотреть, если для начала я просто хочу реализовать абсолютно то же самое что реализовал выше, но с помощью PHP?
Смотреть в сторону enb-bh-php
. Это пакет, который соберет шаблоны в бандл вида desktop.bundles/pagename/pagename.bh.php
. Этот файл предоставит объект $bh
с методом apply()
. Остается передать ему содержимое desktop.bundles/pagename/pagename.bemjson.js
, чтобы на выходе получить HTML-строку, которую можно сохранить на диск или вернуть пользователю в ответ на запрос — зависит от решаемой задачи.
Кроме того, если есть желание использовать блоки из библиотек bem-core
и bem-components
, есть смысл подключить в сборку библиотеки с PHP-шаблонами для них:
@zxqfox
enb-bh-php собирает bh.php точно так же, как и enb-bh собирает bh. После сборки надо будет подключать себе файлы с шаблонами и делать $bh->apply(['block' => 'page']).
@tadatuta
После сборки в $bh будет объект с методом apply, содержащий знание про все шаблоны нужного бандла.
Всем пример. У меня htmlpage.bh.php НЕ появился после enb make. В директории htmlpage лежал только htmlpage.bemjson.js
. Собрался html, css, javascript. Но ничего для PHP нет. Пакет enb-bh-php
установлен.
необходимо добавить знание про сборку bh.php в .enb/make.js
. Про конфигурацию ENB см. https://ru.bem.info/tools/bem/enb-bem/
@tadatuta спасибо за ссылку, так же весьма оказалось полезным, но не удалось найтии информацию про знание для php.
Смотрел тут, тут и тут. По информации с последней страницы даже выполнил npm install --save-dev enb-bh
, но после enb make страницы для php не появились. Как добавить знание про PHP в make.js, как оно выглядит так и не понял.
Так же почитал общую информацию про enb, в частности заинтересовала информация на странице Сборка страницы Ранее у меня возникал вопрос об обязательности decl.js файла, ответ был, но я его не понял. Если верно понял информацию с этой страницы, то в decl.js файле нет необходимости, если в пачке есть *.bemjson.js файл, в котором описаны все необходимые блоки. Если же такого нет, то decl.js файл будет обязательным, верно? К сожалению пока не догадываюсь для каких задач это надо, но предполагаю что такая возможность реализована для удобства использования node.js и написания серверного кода на javascript... На странице нигде не сказано что произойдёт, если разместить и bemjson.js и decl.js (там только про deps рассказано) - что будет в приоритете. Провёл эксперимент, в decl.js указал блок, которого нет в bemjson.js - в результате в min.js и min.css он не попал всё равно. Считать этот результат закономерным или это случайностью? Далее есть такая строчка
NB-конфиг (.enb/make.js) будет выглядить следующим образом
У меня конфиг в project-stub существенно отличается, бросается в глаза browser-js
против js
на странице про процесс сборки. Где можно посмотреть какие технологии для enb make.js устаревшие, какие в себя включают подтехнологии и т.д.? На первый взгляд по конфигу из project-stub рулит js и css borschik...
К сожалению пока не догадываюсь для каких задач это надо
Все просто. Сборщику нужно знать ЧТО конкретно собрать предстоит. Эти знания хранятся в bemdecl.js файлах.
@kompolom вопрос был не об этом
@alexanderbondarchuk А в чем тогда?
Я попробую рассказать общую идею, возможно это автоматически ответит на часть прозвучавших вопросов.
css
, js
или php
-файлы. Это все равно просто текстовые файлы, которые нужно найти по декларации на заданных уровнях переопределения (читай «в указанных папках») и собрать в один или несколько бандлов.@import
с путем до каждого нужного файла. Для PHP это могут быть include
.
Более сложные случаи могут включать дополнительные действия вроде компиляции, минимизации, обфускации и т.п.Документация на тему: https://github.com/enb/enb/#Как-написать-свою-технологию Ну и исходники существующих технологий должны быть более-менее понятные.
Ранее у меня возникал вопрос об обязательности decl.js файла, ответ был, но я его не понял. Если верно понял информацию с этой страницы, то в decl.js файле нет необходимости, если в пачке есть *.bemjson.js файл, в котором описаны все необходимые блоки. Если же такого нет, то decl.js файл будет обязательным, верно?
decl.js
всегда необходим для сборки, но если есть bemjson.js
, его можно сгенерировать автоматически. За это отвечает вот этот шаг сборки.
Соответственно, если этот шаг в конфиге присутствует, decl.js
при пересборке будет перетираться автосгенерированным.
пока не догадываюсь для каких задач это надо
decl.js
стоит писать руками, когда bemjson.js
генерируется в рантайме (в зависимости от роута, в результате похода в БД и т.д.). Т.е. мы заранее собираем все нужные бандлы для всех возможных сущностей, а HTML создаем в ответ на запрос пользователя, а не на этапе сборки.
У меня конфиг в project-stub существенно отличается, бросается в глаза browser-js против js на странице про процесс сборки. Где можно посмотреть какие технологии для enb make.js устаревшие, какие в себя включают подтехнологии и т.д.? На первый взгляд по конфигу из project-stub рулит js и css borschik...
В project-stub
используются актуальные версии актуальных технологий. Кроме того, у технологий для сборки более-менее неплохая документация, из нее должно быть понятно, какие и для чего стоит использовать.
Ну и, наконец, конкретно про сборку bh.php
. Кроме собственно установки пакета, необходимо добавить его вызов в .enb/make.js
. Как это сделать написано в ридми к пакету: https://www.npmjs.com/package/enb-bh-php
В качестве примера можно попробовать посмотреть на https://github.com/bem/project-stub/blob/php-bem-bh/.enb/make.js#L68-L74
@tadatuta приветствую. Создать файл удалось, но были проблемы и есть вопросы.
Проблемы 1.Может быть неправильно читаю инструкцию к пакету, но указанная там команда мне не помогла. Добавил её в самый конец, но после enb make файлы bh.php не появились:
nodeConfig.addTargets([/* '?.bemtree.js', */ '?.html', '?.min.css', '?.min.js']); nodeConfig.addTech(require('enb-bh-php').bhPhp);
2.Решил добавить информацию из другого предоставленного примера, сборщик начал ругаться на конфликт технологий.
Error: Concurrent techs for target: htmlpage.html, techs: "bemjson-to-html" vs "bemjson-to-html"
Закомментил такую строку
//bond bemjsonToHtml: require('enb-bemxjst/techs/bemjson-to-html')
Появилась другая ошибка
TypeError: TechClass is not a function
Нелогично, но решил поискать всё что связано с bemjsonToHtml, решил закоментить следующее
//bond [techs.bemjsonToHtml],
Ошибка изменилась
Error: Concurrent techs for target: htmlpage.bh.php, techs: "bh.php" vs "bh.php"
Закоментил добавленную с помощью первой инструкции строку
//bond nodeConfig.addTech(require('enb-bh-php').bhPhp);
После сборки файлы bh.php появились, но смущает инфо сообщение
[deprecate] [/home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex/node_modules/enb-bh-php/techs/bemjson-to-html.js(20.21)] require-or-eval is deprecated. Please use enb-require-or-eval.
Вопросы 1.Хоть сборка и прошла, но файл htmlpage.bh.php выглядит так,
<?php
require_once __DIR__ . "/../../vendor/bem/bh/index.php";
$bh = new \BEM\BH();
$bh->setOptions(json_decode("{\"jsAttrName\":\"data-bem\",\"jsAttrScheme\":\"json\"}", 1));
return $bh;
а htmlpage.bemjson.js для него так
module.exports = {
block : 'page',
title : 'Title of the page',
favicon : '/favicon.ico',
head : [
{ elem : 'meta', attrs : { name : 'description', content : '' } },
{ elem : 'meta', attrs : { name : 'viewport', content : 'width=device-width, initial-scale=1' } },
{ elem : 'css', url : 'htmlpage.min.css' }
],
scripts: [{ elem : 'js', url : 'htmlpage.min.js' }],
mods : { theme : 'islands' },
content : [
{
block : 'hardlabel',
js: true,
content : [
'Мой первый успешный блок'
]
}
]
};
Что-то они совсем не похожи по моему... Или я не правильно понял смысл сборки bh.php?
2.Хоть всё что связано с html отключил, такие файлы всё равно появляются в сборке, но в какой-то сокращённой вариации. Зачем?
<div class="page page_theme_islands"><div class="hardlabel i-bem" data-bem="{"hardlabel":{}}">Мой первый успешный блок</div></div>
@zxqfox Лёша, можешь, пожалуйста, актуализировать ветку в project-stub
для bh-php? Мне ее потом проверить не на чем :(
@alexanderbondarchuk Можем заскайпиться и разобраться уже с конфигом ;)
@kompolom Евгений, буду рад такой помощи. Я там a_bondarchuk. Кинь туда сообщение, договоримся о времени.
@tadatuta Пожалуйста: https://github.com/bem/project-stub/commits/bem-core-php
Всем привет. В основной моей теме с вопросами по созданию проекта на PHP никто не отвечает, приходится создавать новую =(
Как новичок в этой методологии могу с уверенностью сказать, что самостоятельная точка входа в тему БЭМ за пределами понимания рядового разработчика (по крайней мере говорю о себе). Человеку никогда не работавшему с технологиями используемым в полном стеке БЭМ кроме того что изучить эти технологии, нужно понять как использовать их вместе. Всякие deps файлы, bemtree, bh и т.д. А ещё всё это собирается с помощью ранее неизвестного мне enb, требует установки node.js, хотябы какого-то понимания что такое npm и bower. Человеку всю жизнь использовавшему PHP и C# это начинает казаться реально непростой задачей. Прочитав bem.info думаешь прекрасная концепция, всё понятно. Но берёшься за дело и понимаешь что всё прочитанное ты или забыл, или не правильно понял и всё не так просто. Приходится спамить этот форум или методом тыка и перечитыванием информации искать решение...
В общем: 1) Скачал project-stub 2) Дополнил его библиотекой bem-core-php 3) bem-components-php НЕ СТАВИЛ, ибо пока не знаю зачем оно надо. Других непонятностей итак навалом 4) В папке desktop.bundles пачку index трогать не стал, создал свою firstpage. Положил в неё файлы firstpage.php и firstpage.bh.php, наполнил их в соответствии с примерами из инструкции к установке bh-php (эти примеры заработали у меня) 5) Чисто ради интереса решил попробовать собрать, ниже лог
[failed] [desktop.bundles/firstpage/firstpage.bemjson.js] С одной стороны понятно, что мол нет структуры страницы описанной в bemhtml формате. С другой стороны непонятно - firstpage.bh.php разве не то же самое? Обязателен ли этот bemjson как отдельный файл несмотря на то, что я хочу делать проект на php?
[failed] [desktop.bundles/firstpage/firstpage.bemdecl.js] Очень плохо понимаю что это за файл и если не ошибаюсь он не обязателен для сборки проекта с 1-2 блоками и минимальной js функциональностью для них? Для php он нужен вообще?
[failed] [desktop.bundles/firstpage/firstpage.html] Зачем этот файл должен быть в проекте, если мы структуру описываем в bemjson и с помощью шаблонизаторов этот файл должен создаваться как раз таки из этого bemjson. Или я не прав?
[failed] [desktop.bundles/firstpage/firstpage.deps.js] Это я так понимаю как раз то что мне давно надо - привязывает блоки описанные в desktop.blocks к моей firstpage? Если верно понимаю описание технологии DEPS, то способ формирования страницы, который я пытаюсь реализовать с помощью bh-php является динамическим?