Войти с помощью github

Читаю задачу-пример из документации, вот ссылка на задачу https://ru.bem.info/technology/bemhtml/2.3.0/reference/#%D0%92%D1%8B%D0%B1%D0%BE%D1%80-%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD%D0%B0-%D0%B2-%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8-%D0%BE%D1%82-%D1%80%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%BE%D0%B3%D0%BE-%D1%8D%D0%BB%D0%B5%D0%BC%D0%B5%D0%BD%D1%82%D0%B0 не могу никак понять следующие моменты: 1) в какой моде будет применен данный шаблон, при том, что мода в нем не указана block('listitem').match(!this.inListItem)(apply({inListItem:true}))?.. 2) предположим, что все же я чего-то недопонял и все-таки шаблон из моего 1-го пункта все-таки выполнился. Все, что делает метод apply(исходя из документации) - "Конструкция apply предназначена для явного вызова процедуры выбора и выполнения шаблона, предикат которого истинен в данном контексте. Конструкция позволяет вызывать шаблоны в модифицированном контексте.". Иными словами метод apply в задаче-примере всего лишь изменит свойства текущего контекста(сугубо на время выполнения apply, после выполнения apply свойство inListItem вернется в свое начальное значение до вызова apply) и возвратит результат выполнения подходящего шаблона. Каким боком(при том, что inListItem после завершения вызова apply откатился к своему первоначальному значению) в задаче-примере пытаются заюзать inListItem в block('para').match(this.inListItem).tag()('')? 3) правильно ли я понимаю, что, если в теле шаблона я попытаюсь записать что-либо в нестандартное свойство контекста, например, вот так block('b1').content()(function(){this.HELLO = 'world'}), то после этого свойство HELLO будет доступно в контексте любого последующего обрабатываемого узла bem дерева? Либо при обработке каждого нового узла бэм дерева контекст(объект по ссылке this) пересоздается заного и, в связи с чем, поле HELLO будет отсутствовать для всех последующих обрабатываемых узлов bem дерева?

Заранее благодарю.

В статье http://ru.bem.info/tutorials/start-with-project-stub/ используется project-stub из ветки master и там совсем странный результат получается.

После нескольких попыток подобраться к данной технологии, стало ясно - отсутствие документации никак не продвинет технологию в массы.

Читать, что-то на форумах, в каких-то статьях и не понятном разделе "Руководства" - очень интересно, но кроме каши не дает ничего.

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

Нет примеров кратких но самодостаточных, большинство тем возникали на форуме.

Нигде не сказано, что новым трендом в данной технологии является выделения mVc в отдельный bundle design. Изобилие bem и enb в разных статьях, в документации должно быть что-то одно.

Ситуация вводящая в ступор:

  • создаем страницу bem create -l desktop.bundles -b index на выходе получаем один файл index.bemjson.js;
  • компилируем bem make, на выходе еще получаем 10 файлов.

WTF? Что за файлы, за что отвечают, являются ли они build файлами и не подлежат ручному редактированию? Почему финишные файлы называются по разному, например index.html _index.css _index.js? Нельзя ли результат компиляции, что не подразумевает ручного редактирование перенести в подпапку distr например?

Очень нужна документация, по каждой технологии, устаревшие технологии документировать не первостепенно. Показывать примеры и с подгрузкой данных через API, и динамическое изменение DOM.

Из того, что не критично, но хотелось бы получить:

  1. право переопределять константы BEM_CLASS и BEM_PARAMS_ATTR, ну не нравится мне i-bem и data-bem, хочу получить js и data-js;
  2. не нравится именование модулей i-bem__dom, i-bem как-то не вписывается в Code Style.

Из документаций которые покрывают 99% вопросов мне нравится https://docs.djangoproject.com/en/dev/ http://symfony.com/doc/current/index.html http://git-scm.com/doc - это те документации, которые рассказывает и о различных приемах, и о назначении, и полноценные use case.

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