Я думаю, что БЭМ должен начинать интегрироваться в службы хостинг-провайдеров (поддерживающих Node.js) и предоставляться клиентам как сервис. Это будет способствовать популяризации БЭМ. Стратегическая маркетинговая кампания БЭМ должна разворачиваться вокруг «облачных вычислений» enterprise-уровня в секторах B2B, B2C, B2G, G2G, G2B, G2C.
Архитектура БЭМ должна абстрагироваться (выйти за пределы Node.js) → получить описание по аналогии AST (Abstract Syntax Tree). Я подразумеваю архитектуру алгоритма фреймворка, а не описание данных, которые он обрабатывает. Абстрагирование БЭМ создаст благоприятные условия для реализации методологии на других языках программирования и производных диалектах, что обеспечит полноценную интеграцию на различных целевых платформах корпоративных клиентов и провайдеров SaaS/PaaS. Необходимость в абстрагировании можно аргументировать следующим — не все корпоративные клиенты согласятся устанавливать (или использовать) Node.js, чтобы функционировал БЭМ (правда, при детальном анализе рынка, природа и количество аргументов сильно увеличится). Абстрагирование — это первый шаг к созданию полноценной спецификации БЭМ. Наличие спецификации, позволит корпоративному клиенту самостоятельно реализовать методологию БЭМ исходя из особенностей его целевой(вых) платформ(ы) и языка(ов) программирования, которые он использует для решения своих бизнес-задач. Я говорю о том, что методология БЭМ должна расширять свои границы: становиться полиморфной и полилингвистической моделью организации информации. Вместе с этим, методология БЭМ должна сохранять свои постулаты в изменяющихся условиях операционной среды (в которой она выполняется) и не зависеть от технологии (на которой она реализована).
Очередную веху в развитии БЭМ я вижу в нахождении путей эффективного взаимодействия с UML, IDEF, DFD.
Одна конкретная реализация методологии в виде сборщика + шаблонизатора + библиотеки блоков — да, завязана, но на сегодняшний день существует множество реализаций, включая php, perl, python и ruby.
А что предоставлять в виде облака, учитывая, что сейчас есть куча облаков, предоставляющий node.js?
Можешь привести реальные примеры чего не хватает и как это можно было бы применить на каком-то проекте?
Скорее всего, я не достаточно точно обозначил контекст в певром абзаце своего текста (см. выше → предложение о внедрении БЭМ как сервиса облачных вычислений). Постараюсь исправить свой недочёт следующим образом: a) дополню контекст словом tool; б) ссылка-пример на листинг инструментариев облака, среди которых должен присутствовать БЭМ как инструмент; ссылка-пример на возможный вариант реализации БЭМ как инструмента предоставляемого «облаком». В любом случае, реализация инструмента (tool) зависит от архитектуры конкретного «облачного» сервиса.
Вместе с UML/IDEF/DFD, я рекомендую смотреть в сторону стандартов UN/EDIFACT и ANSI X.12. Это поднимает БЭМ в сектор Electronic Data Interchange (EDI), что автоматически даёт возможность работать на европейском и американском рынках (например, с логистическими компаниями). Чтобы войти в сектор EDI, БЭМ должен стать стандартом. Что даёт реализация UML/IDEF/DFD, UN/EDIFACT и ANSI X.12, интеграция в облачные вычисления? → возможность гибкой интеграции БЭМ в ERP-системы.
Теперь, вернёмся к твоему вопросу: А что предоставлять в виде облака, учитывая, что сейчас есть куча облаков, предоставляющий node.js? Я отвечу на твой вопрос иначе, но в форме встречного вопроса: Сколько «облаков» предоставляют своим клиентам API для работы с EDI и/или международными отраслевыми стандартами (в сфере торговли, промышленности и т.д.)? Очень сложно ответить на данный вопрос без предварительного анализа рынка. Чтобы стать драйвером рынка облачных вычеслений — нужно предлагать инструменты для бизнеса, а не место для бизнеса. БЭМ с поддержкой UML/IDEF/DFD и UN/EDIFACT/ANSI X.12 — это стартовая версия такого инструмента, который решает задачи строго в своей плоскости и обозначенных стандартами пределах.
Вместе с этим, прекрасным расширением функционала фреймворка станет создание панели управления проектом (так называемая project dashboard), где можно создать собственную модель управления проектом, либо реализовать существующие модели и методологии (например, Agile, Waterfall, PMBoK\PMI и т.д.). DOM/JavaScript/
jQuery/Canvas/CSS ⇔ Node.js/MongoDB → набор для создания draft-версии bem project dashboard. Я думаю, что не каждый фреймворк имеет в своем составе project dashboard или поддерживает аналогичные решения на серьёзном уровне.Что на счёт аутсорсинга?
Если одна часть работы над проектом осуществляется на сервере A компании An, другая часть работы над проектом осуществляется на сервере B компании Bn, итоговая сборка всего проекта должна осуществляться на сервере V компании Vn, при условии, что все серверы являются удалёнными по отношению друг к другу. Компании An, Bn, Vn используют фреймворк БЭМ.
Два вопроса. Конкретно.
Можно ссылку на реализацию методологии на php и python?
Можно взять самый простой хостинг с php и mysql и использовать bem?
https://github.com/zxqfox/php-bem
https://github.com/arhibot/python-bem
Но на этом вариации на тему далеко не исчерпываются:
http://tech.yandex.ru/eve
http://tech.yandex.ru/eve
http://www.jetstyle.ru/novosti/2013/6/4/18957
http://www.futurecolors.ru/
Вариантов реализации с той или иной полнотой действительно огромное множество.
2. Что подразумевается под «использовать БЭМ»?
Писать CSS в БЭМ нотации — это ведь уже использовать БЭМ.
Разносить код на файловой системе по блокам, а не по технологиям, как обычно — тоже использовать БЭМ. Писать декларативный js в БЭМ-терминах, строить взаимодействие в команде по методологии, использовать инструменты в разработке. И т.д.
Для всего этого серверное окружение вообще не играет никакой роли.
Если вопрос был про сборку, то сборку нужно делать в процессе разработки, а на сервер выкладывать уже собранный результат, так что для сборки серверное окружение тоже значения не имеет.
Если же речь о том, чтобы использовать шаблонизатор BEMHTML в динамике, то потребуется php с поддержкой v8js на сервере.
можешь привести пример типа «сейчас БЭМ делает а) б) в), нужно добавить г) д) е) и станет хорошо»?
Если я правильно понимаю реализацию на PHP можно только в лабораторных условиях использовать.
Или я ошибаюсь, в том что на PHP есть один экспериментальный проект и называть это реализацией будет не верно.
upd: в любом слючае это реализация и не важно эксперементальная, я хочу сказать, что важно делать учточнение о том какой готовности реализация.
Проблема в архитектуре пхп и медленном запуске v8js.
php заточен, чтобы запускаться очень часто, когда как v8js хочется демонизироваться, и тут конфликт интересов, потому и медленно.
Я пришел к выводу, что запустить рядом с апачем proxy на nodejs, который будет собирать странички — изички и решает этот конфликт. Так что, рекоммендую использовать эту схему,
Допустим я хочу собирать bemhtml на клиенте. Где я могу про это прочитать?
чтобы код собранных шаблонов попал в клиентский js, нужно описать зависимости вот таким образом: http://ru.bem.info/tools/
Шаблоны попали на клиент. Как теперь качать на клиент бэм-дерево и применять к нему шаблон? Какой результат получится и что с ним делать дальше?
1. делаем запрос за данными, например, через $.ajax(), получаем массив записей типа [{ title: 'first', content: 'content of the first item' }, { title: 'second', content: 'second item content' }].
2. пишем функцию, которая построит из этих данных bemjson:
var data2bemjson = function(data) {return data.map(function(item) {
return {
block: 'post',
content: [
{
elem: 'title',
content: item.title
},
item.content
]
};
});
}
(Либо можно использовать bemtree-шаблоны для этой же цели).
3. Остается сделать
BEMHTML.apply(data2bemjson(data)
Ага, я кажется начал понимать. В блоке любой страницы, помимо
_*.js _*.css *.html *.bemjson.js, есть также*.bemhtml.js, который является скомпилированным в javascript модулем, который экспортирует шаблонизатор в window.BEMHTML. Мне удалось с одной страницы получить bemhtml шаблон и bemjson дерево другой, наложить их:eval(bemhtml); var doc = BEMHTML.apply(eval(json));получился html другой страницы.
Я обновил страницу вот так:
document.write(doc);PS: на всякий случай уточню: eval и document.write — это ведь только для примера? использовать их на реальном проекте — зло.
Может есть готовые цифры, сколько шаблонов может потянуть bemhtml?
eval(json)не обошлось, потому что JSON.parse не может обработать bemjson:({ ... })А можно делать так:
JSON.parse(json.slice(1, -1))1. не индексируется поисковиками (не является проблемой для веб-приложений, где контент в принципе не подразумевает индексирования).
2. страница отрисуется только после того, как отработает js, т.е. чуть-чуть медленнее, чем если бы браузер получил готовый html.
для решения этих моментов хорошо сочетать оба способа генерации: при обычном get-запросе отдавать готовый html, сгенерированный теми же шаблонами на сервере, а при ajax-запросах — строить html на клиенте.
ограничений нет, вопрос лишь в том, чтобы не гонять явно избыточные данные.
Согласен с @tadatuta, как-то слишком абстрактно. Хотелось бы ближе к телу.
К сожалению, не получится делать JSON.parse:
- bemjson это не json в скобочках, это все таки js.
- bemjson может включать какие-то специальные вставки, которые собираются в функции.
Но если вы будете писать правильный JSON и вставки вам не нужны, то и скобочки тоже можно опускать.
А как же тогда быть?
Если собираете на сервере — то vm.runInThisContext или что-то рядом, если на клиенте — отправляйте туда правильный JSON, и нет проблем
Я просто уточняю, что bemjson в том синтаксисе, который представлен в блоках, со скобочками, без кавычек — не является валидным JSON.