Друпал хороший, используйте его, преодоление его порога вхождения дорого стоит. Мы не стремились сделать лучше чем в другой cms, а реализовывали свои идеи для эффективной разработки сайтов, их поддержке, возможности отходить от типовых решений, удовлетворяя фантазии клиентов да и возможность свои проекты быстро реализовывать, наслаждаясь процессом и результатом. Все похожести случайны из-за схожести решаемых задач.
Готовность «всегда быть готовым» для использования заложено в архитектуре движка, какая бы связанность не была. Вся связанность на уровне структуры данных. Если нужны новые связи, не нужны существующие — они изменяются. Обратите внимание на повторное использование прототипированием — это создание нового с последующей возможностью подстроить под свои нужды. Сохранится связь для обновлений, не нужно копипастить и не портится оригинальный модуль (объект).
Натягивание дизайна сводится к нарезанию html на виджеты. Если это простейший сайт, можно обойтись одним виджетом — всю верстку сделать в его шаблоне. Минут 5 хватит. Если проект сложный, то потребуется больше знаний, опыта. Движок не пытается заменить специалистов на домохозяек, но делает их работу эффективней.
Сейчас движок — это инструмент для создания сайта. Понятия коробки ещё нет, даётся удобство для создания своей коробки, для создания функций в точном соответствии с требованиями проекта или деятельности вебстудии. Конечно, мы планируем выпустить «коробки» под конкретные категории проектов/пользователей.
Главная особенность – повторное использование всего, что создаётся. Заботиться о создании «модулей» не нужно. Любой объект проекта всегда готов для повторного использования, для улучшения, подстройки под другие задачи.
Каждому своё и в этом движок не отказывает, хоть десять разных визивиков поставьте. В обще, если детализировать текст на абзацы, то можно получить редактор текста с уникальными особенностями — в сам текст добавлять любые объекты, связывать абзацы между разными статьями, чтобы не дублировать их. Мы над таким редактором работали, получался своеобразный гугл.докс. Релиз редактора отложен на будущее ))
Функции админки настраиваются под разные категории пользователей, добавляются или срываются специфичные функции. В статье кратко, может от этого незаметно, сказано, что под особенности проекта добавляются узкоспециализированные функции редактирования. На вопрос, кто будет ею пользоваться — сперва отвечу Я! ) Но вам, спасибо, вы заставляете ещё раз возвращаться к интерфейсу админки, для нас работа над ней оказалась одной из самой сложной.
Глядя на реальный проект, из которого придуман пример, не могу согласится, что это глобальный модификатор. Это модификатор конкретного блока (первого). В нём он имеет смысл, определяет поведение и внешность блока. В других блоках в любых уровнях он не нужен или будет иметь другой смысл. Тут явная зависимость от родительского блока. Могут быть примеры с большой вложенностью, где модификатор влияет только на непосредственных детей или с какой-то там структурой. Это всё решается каскадом, да, с вытекающей из этого зависимостью блоков. Я, собственно, о том, что от зависимости не уйти, применяется ли БЭМ или нет.
Всем, кто хочет улучшить свою верстку я бы только рекомендовал минимизировать какскад, применять соглашения об именовании классов и не жертвовать совместимостью со всем, что в вебе напридумывали и придумают ещё. Полностью следуя методологии BEM и применяя её инструменты, ощущаю себя в песочнице отстраненным от прогресса :)
Блок в состоянии выделения, допустим, меняет фон на чёрный. У второго блока фон прозрачный, но цвет его текста желательно поменять на белый. Как в BEM в зависимости от состояния первого блока поменять стиль второго блока?
Варианты:
Блоки независимы, можно считать проблемы нет. Второму блоку нужно задать свой фон. И пофиг какое состояние у первого блока. Получим неадекватный дизайн. Для полной независимости нужно всем блокам определять все свойства стиля, иначе ложно утверждение, что блок везде будет выглядит одинакового (не поедет его стиль). Но тогда не применить множество классов на тег.
Второму блоку тоже добавляем модификатор (свой), чтоб менял цвет и фон. Хм. Кто его будет добавлять? Логика первого блока? Но блоки независимы, т.е. нет знаний, какие блоки могут оказаться внутри первого и от куда узнать, какие им модификаторы добавлять? Пробуем каким-то образом обрабатывать событие выделения логикой второго блока, чтобы он сам себе модификатор добавлял. Но и тут проблема независимости. Изначально неизвестно внутри какого блока окажется второй блок и, соответственно, при каких событиях добавлять модификатор? Сам модификатор по смыслу зависим от первого блока. И от куда второй блок должен знать, что ему нужно именно в черный цвет краситься? Опять зависимость от первого блока.
Применяем каскад. .block_select_on .block2{} Где писать этот каскад, в css первого, второго блока или в css проекта? Ладно, на уровне css/html получается лаконично. Но где желаемая независимость блоков? Разработчик первого блока ещё может догадаться, что в его блок будут добавлять другие блоки, и им нужно менять оформление, но неизвестно что именно менять (структура блоков неизвестна). Разработчик второго блока даже и не думал об особенностях отображения внутри неопределенных им блоков.
Мы хотим независимость, когда всё пропитано зависимостью? Каков компромисс?
Классы BEM быстрее обрабатываются. Стараемся не использовать каскад
CSS BEM независим от структуры HTML. И в целом меньше проблем со стилями вложенных блоков
Каскад применяется там, где BEM неприменим, где зависимость от конекста. Но мне до сих пор не понятно, как это урегулировано в самом BEM и его инструментах. Как в BEMJSON указать такую зависимость?
Необходима база именованный блоков для соблюдения уникальности и возможности взять за основу существующий блок
Грабли с применением jQuery и других скриптов. Например, не можем с легкостью добавить любой кнопке состояние нажатия (класс), так как название модификатора состоит из имени блока. Приходится использовать дополнительные обертки.
Чтобы оформление хоть как-то зависело от темы, необходимо добавлять в HTML своего блока классы базовых блоков. Например button, input, title. Но здесь проходит тонкая грань независимости, нужно предполагать, что определяют классы базовых блоков.
Вместо каскада работаем с длинными перечнем классов в теге.
Независимость зависима от решений, что считать блоками?
Приводится пример: «с БЭМ легко перенести блок из левой колонки в правую». А что если этот «блок» при проектировании считался элементом для колонки? Значит элементов в обще не должно быть, каждый тег — независимый блок. Каждому тегу свой класс?
Для независимости блоков делаем классы без каскада, хорошо, но почему для элементов нельзя применять каскад от класса блока, ведь они уже зависимы от своего блока? И модификаторы также.
А какая РСУБД может возвращать дерево вместо списка найденных записей? Обычно этот метод комбинируется с AL (в pages добавляется parent_page) для простоты формирования дерева из списка выбранных записей.
Всем, кто хочет улучшить свою верстку я бы только рекомендовал минимизировать какскад, применять соглашения об именовании классов и не жертвовать совместимостью со всем, что в вебе напридумывали и придумают ещё. Полностью следуя методологии BEM и применяя её инструменты, ощущаю себя в песочнице отстраненным от прогресса :)
В какой-то момент первому блоку добавляется модификатор (состояние)
block_select_on, что он выделен:Блок в состоянии выделения, допустим, меняет фон на чёрный. У второго блока фон прозрачный, но цвет его текста желательно поменять на белый. Как в BEM в зависимости от состояния первого блока поменять стиль второго блока?
Варианты:
.block_select_on .block2{}Где писать этот каскад, в css первого, второго блока или в css проекта? Ладно, на уровне css/html получается лаконично. Но где желаемая независимость блоков? Разработчик первого блока ещё может догадаться, что в его блок будут добавлять другие блоки, и им нужно менять оформление, но неизвестно что именно менять (структура блоков неизвестна). Разработчик второго блока даже и не думал об особенностях отображения внутри неопределенных им блоков.Мы хотим независимость, когда всё пропитано зависимостью? Каков компромисс?
Приводится пример: «с БЭМ легко перенести блок из левой колонки в правую». А что если этот «блок» при проектировании считался элементом для колонки? Значит элементов в обще не должно быть, каждый тег — независимый блок. Каждому тегу свой класс?
Так и есть. Без ограниченности глубины дерева, лучшей скорости поиска и другого