Являемся разработчиками темы https://www.webasyst.ru/store/theme/juicer_land/ в которой мы переделали оформление заказа, в частности доставка была представлена в виде вкладок аккордиона, за основы была взята тема для разработчиков Dummy. В итоге пришлось много переделать и изменить расположение элементов чтобы страница оформления заказов смотрелась красиво.
В итоге столкнулись с массой проблем!
Почему-то большинство плагинов доставки привязываются к теме default! и не только к классам а еще и DOM структуре! из за чего пришлось внедрить не нужный в нашей теме ul li
При попытки связаться с разработчиками плагинов чаще всего получали следующий ответ, плагин работает на теме default идите нафиг используйте структуру данной темы оформления.
Некоторые плагины вообще пытаются получить информацию из классов:
var changed_m_id = $(this).parents('li').attr('class').replace('shipping-', '');
в итоге получаем changed_m_id = "5 is-selected" что в дальнейшем вызывает ошибку
Даже тема dummy привязывается к DOM структуре
$wrapper.find("input:radio").on("change", function () {
а если я хочу не radio, а select использовать?
Крик души прошел, теперь конструктив!
1) Предлагаю разработчикам webAsyst строго регламентировать структуру блоков оформления заказов по методологии BEM!
Использовать только жестко регламентированные классы без привязки к оформлению и DOM стуркутуре (опять же БЭМ)
s-delivery
s-delivery__name
s-delivery__rates
s-delivery__error
s-delivery__address и т.д.
и определить (лучше конечно прямо на картинке, за что какой класс отвечает)
это пытались сделать в теме Dummy но не до конца, одни и те-же стили использовались и для скриптов и для оформления.
Все данные необходимые для работы получать и хранить в data- атрибутах, чтобы не было никаких вытаскиваний непонятно откуда:
var changed_m_id = $(this).parents('li').attr('class').replace('shipping-', '');
поменялся бы на
var changed_m_id = $(this).closest('.s-delivery').data('id');
и никаких бы ошибок никогда не возникло бы при любой теме оформления!
2) После разработки данной структуры уведомить всех разработчиков о необходимости обязательной поддержки данной структуры вплоть до удаления из каталога
3) Запланировать версию обновления shop-script в которой прекратить поддержку плагинов и тем не поддерживающих данную структуру
101 комментарий
Начинание интересное, но не понятно при чём тут БЭМ и жёсткая привязка к классам.
Рекомендую ознакомиться с требованиями в Magento http://devdocs.magento.com/guides/v2.0/coding-stan...
Business logic must rely on only the form, form element name attributes, or data attributes
Да и вообще там много интересного, что можно подсмотреть.
БЭМ это отличная методология решает те-же задачи что и в скинутой вами ссылки но намного понятнее и проще. А идея та-же разделить бизнес логику и отображение.
Магенто очень огромная система по сравнению c Shop-script и порог входа в нее очень высок.
Почему БЭМ - потомучто это в первую очередь методология, а реализация возможно какая угодно, поэтому ее можно использовать везде, во вторую - потомучто уже довольно известная и редко встречаются сайты не использующие ее в той или иной мере (кстати google хоть и конкурент яндекса, но тоже использует данную методологи в своих некоторых проектах)
Кто не в курсе: https://ru.bem.info/methodology/
Кому понятнее и проще? Аргумент из разряда: потому, что я использую... и Яндекс... и Гугл.
Проблема же не решается
и дальше будут. Только теперь ещё и новые классы добавятся.
А так стили к стилям, data-* к скриптам.
Ваш ответ в том же духе, я не использую и другим не нужно.
Как раз проблема решается, не нужно заботится что как выглядит, за механику отвечают свои классы, за отображение свои, можно повесить нужный класс на что угодно и он правильно заработает.
Это как классы btn btn-primary в bootstrape я могу повесить на ссылку на кнопку на инпут и он будет выглядеть как кнопка.
Ситуация со скриптами такая-же, вешаем класс s-delivery__error на что угодно на div span h3 и т.д. и в него выводится сообщение об ошибке.
Вообще БЭМ тем и хорош что не ограничивает реализацию, запросто можно сделать и на data если вам так удобней. Еще раз повторюсь БЭМ это методология с рекомендуемой реализаций (не обязательной)
А вот что нужно так это стандартизировать классы (или data- неважно, но классы привычней) и за что они отвечают. Но без понимания и вовлечения в проект webAsyst это все обречено на провал. Без жесткой политики со стороны webAsyst будет так как вы и говорите: "и дальше будут."
Я клоню к тому, что сама постановка вопроса "вот эти классы используй, но стили вешай на свои" мне кажется абсурдной.
Но идею создания однородной структуры определённо поддерживаю!
Жёсткая политика Webasyst упирается в их ресурсы. О чём уже неоднократно они писали на форуме.
Проверка соответствия JS выбранной структуре классов будет занимать у модераторов больше времени, чем увидел $('.myclass') - нафиг.
Рад что вы тоже за единую идею, вопрос только в реализации.
Да, надеюсь что все таки что то будет, а не пустые разговоры.
Пока можем немного поразглогольствовать пока лесник с метлой не пришел)
Почему идея вам кажется абсурдной?
Потому, что, если утрировать, $('.s-delivery') будет валидным при данном подходе, а $('.c-delivery') - нет. И потом пойди, разберись какие классы нарушают структуру, а какие нет. (Кстати, shipping бы уже использовать, наверное, для однообразия).
Я думаю, что со стороны модерации такая проверка невыполнима (если вообще учитывать, что код проверяется).
В гайдах Мадженты и есть те жестокие правила, которые, с одной стороны возможно выполнить в Webasyst, а с другой стороны возможно проверить.
Остаётся открытым вопрос, что фреймворк не будет соответствовать этим гайдам XD
Ну во первых если примется стандартом s-delivery - он и будет стандартным (можно shipping без разницы)
Ваше решение? Можете пример накидать?
Так ведь суть та же :) просто вместо классов используем data-атрибуты.
$(this).closest('.s-delivery').data('id');будет, к примеру
<ul> {foreach $shipping_methods as $m} <li data-delivery="{$m|@json_encode}"> <button data-button>Просто для примера</button> </li> {/foreach} </ul> <script> $('[data-button]').click(function(){ var $item = $(this).closest('[data-delivery]'), delivery = $item.data('delivery'), id = delivery.id, name = delivery.name; alert('Выбран способ доставки '+name+' #'+id); }) </script>Во-первых убираем зависимость от разметки, а во вторых в JS теперь доступен не только айдишник, а вся информация по объекту доставки.
В принципе большой разницы нет (ну разве что код смотрится немного громоздко, и работает медленне чем селекторы) но не принципиально, можно и так, главное чтобы был регламент наименования и хранения.
А иначе будут опять хранить кто что попало, кто id кто массив кто json
Не более и не менее громоздко..
<ul> {foreach $shipping_methods as $m} <li class="s-delivery" data-delivery="{$m|@json_encode}"> <button class="s-button">Просто для примера</button> </li> {/foreach} </ul> <script> $('.s-button').click(function(){ var $item = $(this).closest('.s-delivery'), delivery = $item.data('delivery'), id = delivery.id, name = delivery.name; alert('Выбран способ доставки '+name+' #'+id); }) </script>В данном случае data-delivery всё-равно нужен (как и классы в примере выше).
По скорости не думаю, что разница будет существенна. Особенно, если предварительно ограничить область поиска.
Это известные танцы с бубнами, некоторые плагины доставки, например СДЭК, вообще привязывается только к тегу H3 в заголовке, поэтому хочешь не хочешь, а используй :)
плагины доставки ни к чему не привязываются. Они вообще сами ничего не выводят. Это у вас тема оформления и ее скрипт к h3 привязывается.
И да. Нафиг БЭМ.
мда, тяжелый случай, уж наверно мы знаем что делает наша тема а что нет, если Ваши плагины не выводят ничего в теме то почему вы так свободно говорите про все плагины?
а там нечего выводить кроме, разве что карты. у нормальных плагинов скрипт вывода карты можно и подменить.
и никто не мешает использовать и стилизовать штатные селекторы WA
Ваша позиция понятна, оставить все как есть, если что не так
идите нафигделайте как в default.Не все идеи решатся просто стилизацией "штатных" селекторов, во первых какие селекторы штатные? каждый думает по своему, мы и предположить не могли что родительский li является "штатным селектором"
во вторых попробйте что нибудь поменять в облаке? где у вас только админка, и если в теме еще что то можно поменять то в плагине нельзя.
У вас есть список методов доставки. Список. В li. Что тут нелогичного-то?
Навскидку li.shipping-id-*, input[checkbox], span.error, span.comment, .price + стандартная форма .wa-form , wa-field, wa-name, wa-value. Ничего не забыл?
Если автор плагина не сделал возможность отключения вывода скрипта и своего css, ему, конечно, нужно попенять на это. Многие авторы читают отзывы и переживают из-за оценок. Сам видел. Поставьте ему 2 звезды, если он отказывается сделать отключение подгрузки своих js/css :)
Ситуация то обычно другая, заказчик купил тему, поставил плагин, плагин не работает, кто виноват?
Разработчик темы который не предумотрел все возможные варианты а взял Dummy за основу? или разработчик плагина который взял default за основу?
Ситуация патовая
А зачем брать dummy за основу? Она не референсная ни разу. Default есть всегда во всех установках для всех приложений (а не только для site/shop).
Хотя я более чем уверен, что в dummy чекаут такой же, как в default
Потому что она позиционируется как именно тема для разработки тем.
И она сильно отличается от default (есть конечно почти идентичный код) но и отличия есть.
если бы default была идеальной темой, то она бы всех устраивала и никто бы не разрабатывал новые темы.
Сходил посмотрел dummy. Там все важные опции на месте. Обратил внимание, вот на что: классы с префиксом s- неважны. Если у элемента есть класс без этого префикса -- то это вещь важная и лучше чтоб это был также точно такой же элемент. Особенно это касается input[radio] и select
Ого, а цену каким образом он пытается считать? Не через h3
Скрипт магазина ему передает данные (которые сам берет из формы), плагин отдает массив вариантов, которые скрипт магазина сериализует в json и передает js-скрипту темы
большинство авторов тем просто копируют js оформления заказа из default в которой есть привязка к h3 и т.д.
поищите в checkout.shipping.html фнкцию responseCallback
Вот в этом и проблема, что поиск идет по тегу H3 для вычисления стоимости доставки, а я допустим не хочу этот тег использовать, почему тогда не привязаться к классу shipping-{$m.id}, ведь он уникальный и обязательно должен присутствовать в теме в отличии от H3.
Но это не плагин доставки. Это тема. Можете взять и переписать или изменить этот js-обработчик, чтобы он другие селекторы искал
Сергей, тогда понял, спасибо!
Я вот кривыми своими руками в Supreme покопался. H3 в названии есть, но к нему не привязываюсь (если кликнуть на картинке правой кнопкой мыши и открыть в новой вкладке размер будет побольше)
атрибуты сила
Тема default -- референсная для всех плагинов. Совместимость с остальными негарантирована
Крик души! я пишу плагин который должен взаимодествовать с элементами темы! И вот что я скажу: все пишут по разному и хрен сделаешь что-то универсально, поэтому те темы которые используют шаблон стандартный проще интегрируются! Те кто полностью отказываются от привычных всем селекторов и элементов, просто не понимают что другим возможно придется работать с их темами! Поэтому спасибо тем кто следует каким то правилам стандартных тем!
ВО и у нас похожая ситуация только с другой стороны) а проблема в том что нет "стандартных селекторов" а если они будут всем будет проще.
А предлагаю совместно разработать JS карту ЭЛЕМЕНТОВ И МЕТОДОВ
Карта это хорошо и задел на будущее, но долго и тяжело сразу делать карту всего сайта, практичнее начать с чего нибудь простого и потом его развить во что-то сложное.
Хотя бы на первом этапе стандарт наименования используемых классов реализовать.
Совместно мы можем разработать что угодно, но без решения webAsyst это все на уровне поговорили и забыли
Ну они тоже нормальным идеям рады
Если бы разработчики тем делали бы js карту элементов было бы проще!
$.waTheme = {}; $.waTheme.Category = { get: function() { return $('.maincontent').children('.container'); }, Description: function() { return $.waTheme.Category.get().find('.description'); }, Filter: function() { return $.waTheme.Category.get().find('.filters'); } }; $.waTheme.Category.ProductList = { selector: '#product-list', get:function () { return $.waTheme.Category.get().find('#product-list'); } }; $.waTheme.Category.ProductList.Products = function() { $.waTheme.Category.get().find('#product-list').find('ul.product-list').children('li'); }; $.waTheme.Category.ProductList.Product = function(selector) { if(selector) { $.waTheme.Category.get().find('#product-list').find('ul.product-list').find(selector).closest('.selector'); } };А также еще и глобальные методы, а не костыли в лябда функциях!
$.waTheme = { setCartData:function(data){ /// принимет массив данных корзины и ставит данные } };А почему ты на наличие jQuery рассчитываешь?
Потому что я если надо проверю и сам подключу если нету его)))
Вот поэтому :)
Эту форму трудно, но можно подменить
В теме? Намёк был на другое: во фреймворке тоже не рассчитывают, что jQuery не будет.
Я, кстати, в первых версиях плагинов проверял, а потом забил.
та же фигня. Но рано или поздно на эти детские грабли кто-нибудь наступит :-|
это конечно простой набросок, но думаю понятно о чем речь в нем!
Вообще это косяк WA. В документации указано, что эта dummy -- шаблон для разработки новых тем. Шаблон, Карл!
А вот о том, что некоторые классы должны быть обязательно и некоторые элементы должны быть очень желательно — ни слова :(
P.S. нафиг-нафиг бэм все равно :-D
а мой вариант норм?
обязательный глобальный объект -- нет
у тебя варианты есть лучше? нужны еще и методы, например обновление корзины updateCart(json_data)... и тд
еще желательно хранить последние данные корзины для манипуляций!!!
Максимум -- даже не обязать, а рекомендовать блоку с корзиной присваивать какой-нибудь класс типа .cart и так же рекомендовать вешать на этот блок обработчик события, например, change
Причем это достаточно сделать в теме default, а оастальные за ней подтянутся :)
Доброго времени суток. О данной проблеме мы знаем. Срочные меры принимать пока не будем, так как существует большое количество тем и плагинов, которые это затронет.
Решение проблемы требует достаточно длительного и тщательного подхода. Мы рассматриваем возможные решения к будущему большому обновлению.
Думаю совместно с вами Марк мы придем к рациональному решению! Мой простой объект я постараюсь сформировать в мини библиотеку, размещу на форуме(+гит), где мы совместно ее допилим..., затем ПЛ в тему DUMMY. Очень надеюсь на ваше сотрудничество и поддержку диалога со стороны компании.
Добрый вечер.
Очень рады что проблемы не игнорируются, а изучаются и обдумываются.
Очень хотелось бы видеть некий roadmap или хотя-бы список готовящихся нововведений?
Думаю, еще его нет))) Сейчас пишут!
Ну сделали аккордеон. Стильно, модно, молодёжно. Молодцы!
Отвалилась половина(утрирую) плагинов оплаты, доставки и пр. которое хоть как-то пытаются работать с фронтэндом чекаута. Виноваты плагины, потому что не имеют ИИ, и не могут понять где что лежит.
Чекаут это (пииик). Вещь в себе. Трогать можно, но очень осторожно.
Проверено несколько десятков тем дизайна и этот вариант был признан рабочим(вашей темы тогда не было видимо?). Сколько было всего потрачено сил на это "хоть как-то", я сейчас не буду -) Кто пытался работать с чекаутом знают как там всё устроено.
Пользователю, который написал мне письмо по этой проблеме я помогу. Если смогу, сделаю патч. Нет - индивидуально. Надеюсь у него не облако.
Александр Тарасенко, мой крик души вы поняли? -)
Зы. БЭМ - хорошо, карты - хорошо, использование data-атрибутов в критически важных элементах - обязательно.
Перекладывать с больной головы на другую больную голову - часть нашей жизни. Увы.
да мы недавно работаем с Shop-script поэтому поэтому некоторые вещи к чему видать все привыкли у нас вызывают много вопросов и мягко говоря непонимание.
Никто не говорит что виноват именно Ваш плагин, я прекрасно понимаю почему так сделано (другово выхода просто небыло).
p.s. ну а так, виноваты те десятки тем и плагинов которые продолжали делать "хоть как-то" вместо того чтобы прийти к единому варианту. Что и пытаемся сейчас пробить натыкаясь на стену непонимания, возмущения, негодования и т.д., дескать и так все было и всех устраивало, а пришли тут и воду мутят) Надеюсь вы поддержите данное начинание, ведь все выиграют только от этого
Если выработаем единый стандарт хотя бы чекуата - хорошо.
Но он вроде как уже есть - в Дефолте. Да, он не идеален и там есть что подправить.
Но. Кто будет этим заниматься? Кто ответственный? Как заставить всех принять эти изменения и сделать массовый рефакторинг?
Это огромная работа.
Подозреваю, что не "ну сделали", а "вставили бутстраповский".
И что в этом плохово? Фремеворки для того и созданы чтобы их использовать, а те кто велосипедят, велосипедьте дальше.
Использовать, а не копипастить. Бутстраповская структура здесь, в этом месте, не подойдет.
Не стоит делать выводы не основанные ни на чем, я не вижу причин почемы вы все воспринимаете в штыки все ищете к чему бы придраться,
вот вы ответьте, вы против чтобы был принял стандарт (не мной, webAsyst) который регламентирует где и как получить необходимые вам данные для работы вашего плагина в любой теме?
Предыдущая версия Webasyst ShopScript имела довольно жесткий стандарт на разметку. В результате этого возникло огромное число индивидуальных доработок, не обновляемых в принципе, что привело к использованию старых версий скрипта с неисправленными проблемами безопасности.
Плюс у многих продуктов уже есть установки. Наверняка многие доработали темы и больше их не обновляют (обычо делают копию и работают с ней), а получат обновление плагина, которое с их темой не совместимо. Им что, что же срочно разметку внедрять? Вы это оплатите?
А не проще вашу тему поправить и разослать обновление?
естественно тему мы поправим, и следующею сделаем по default и будем ее использовать пока не примут наконец то хоть какой-то стандарт (если вообще его примут)
Вы сами предлагаете изобрести гигантский велосипед из-за того, что вам влом сделать маленький трёх-колёсный велосипедик.
Это и есть стандартизация. Она конечно лишь устная и нигде не прописана, но всё же. Тему правильнее было начинать так "Мне тут лень было мучиться и я сделал так, как мне удобнее. Эй вы, переделайте свои плагины под меня".
И какой смысл сейчас обсуждать подобное? Да, обязательное использование data-attrs было бы вполне неплохим решением. Но СЕЙЧАС то что? Заставить переписать все те сотни плагинов? И еще обратную совместимость предусмотреть? Тут есть люди, у которые этих плагинов под сотню. Так что говорю не за себя. Мне то там нечего переделывать. Подобная тема стандартизации поднималась в первые пол года после открытия "аппстора". Тогда на нее закрыли глаза, а вы сейчас чего-то ждете глобального? У нас до сих пор некоторые плагины встаивают свой код с классом аля .tooltip.
И чем вас так раздражает привязка к классам? Если нужного класса нет, то его легко можно добавить. Не зря в бекенде редактирование шаблонов сделали. Это самый простой и гуманный способ. Если клиент настолько далек от всего этого, что не может разобраться, то не вижу сложностей в оказании ему помощи. Накиньте стоимость за это сразу в плагин.
Вы невнимательно прочитали пост, тут как раз и предполагается стандартизация классов (data атриубутов неважно) и не под "меня" а под принятый и утвержденный стандарт.
Если ничего не делать то все останется как и было лет 10 назад, все будут писать как хотят, костыли на костылях, все темы будут похожи на default
Почему то все сразу говорят о трудо затратах, о сложности и т.д. О каких трудозатратах идет речь? заменить одни классы на другие которые будут приняты стандартными?
И да заставить если нужно, кто не перепишет правильно освободит нишу для тех кто перепишет, и как раз и нестанет плагинов добавляющих .tooltip
И мы не делали как нам удобней мы взяли за основу тему Dummy и на основе ее и делали.
dummy-то работает
Спустя год столкнулся с подобной проблемой и коллеги ткнули меня носом в мой же пост. Забавно, но... я не это имел в виду :) Если перечитать внимательно, то можно заметить, что я читал невнимательно. А точнее, я отвечал лишь на предложение по переходу на использование data-атрибутов.
Дополню своё мнение.
Привязка к классам - стандартизация. Привязка к li.class - избыточное искусственное ограничение. Такой подход анахроничен.
Будет очень продуктивно, если вы укажете, какие именно данные нужны для работоспособности ваших плагинов оплаты/доставки из темы?
Мы сможем подготовить виденье решения к понедельнику (на первом этапе оформление заказа - доставка).
Мне нужна карта элементов продуктов в категории!
1. контейнер в котором все продукты (product-list)
2 карта самого продукта :
цена (price)
старая цена (compare-at-price)
картинка <img>
описание краткое short-description
3 Нужен метод для обновления корзины
4 Корневой элемент корзины (#cart)
5 элемент количества продуктов в корзине <span class='count'>
6 элемент суммы корзины (cart-price)
Тема Default – это и есть стандарт!
Я бы даже назвал эталон. В ней работают все заявленные в шоп-скрипте функции. И все разработчики плагинов проверяют свои плагины на ней. А разработчики тем дизайна разбираются, как должна работать их тема тоже на ней!
И если плагин не работает с другой темой дизайна, то это косяк разработчика темы, который не привёл свою тему к общему стандарту. Это я вам как разработчик тем дизайна говорю.
Полезная мысль в вашем послании есть – разделить классы для дизайна и для скриптов.
Но мне кажется, это можно сделать с учётом обратной совместимости, чтобы предыдущие проекты остались живыми.
Лично я терпеть не могу этот ваш БЭМ. Ну очень громоздкая методология! Целая портянка классов у элемента, прибавьте к этому смарти-условия, и строка кода разрастётся на несколько.
То, что дальше – вообще бред!
Сколько у вас уходит времени на разработку темы?
А теперь представьте, что у вас есть десяток тем, в которые вы вложили душу! Вы их сделали на привычной вам теме Dummy по своей любимой методологии БЭМ!
А тут приходит умник, простите, и пишет:
И вот ваша десятка тем летит к чертям! А потом вам начинают писать недовольные негодующие покупатели, которые узнали, что их покупка, возможно, не будет обновляться!
Приятно вам было бы?!
Зато умнику будет всё понятно! Ну и "дорогу молодым"!
В чужой монастырь со своими правилами лезете!
А ничего, что остальным разработчикам нужно будет переучиваться (я имею в виду переосмыслять, менять привычки) на вашу новую методологию?
Ну ещё взгляд с другой колокольни. Сейчас в маркете есть только две темы "соотвествующие вашему стандарту БЭМ" - ваши, на сколько я понимаю. =)
Отличная идея! Давайте всех забаним, и в магазине останутся только ваши две темы!
То, что вы предлагаете – это убийство всех текущих проектов!
А из чего будет выбирать конечный покупатель?
И к кому он уйдёт, мы все знаем!
Если хотите сделать что-то полезное, создайте свою тему BEMDummy – свой стандарт, сделайте её так, как вы видите! Ну и так, чтобы всё работало, естественно! =) И фигачьте свои темы на ней, и те, кому понравится БЭМ тоже будут ей пользоваться.
Вы не разобрались в ситуации а сразу ринулись в драку) Я не говорю, вот моя тема основа используем ее, я хочу как разработчик получить четкий стандарт/регламент оформления жизненно важных данный в темах дизайна.
Чтобы любой разработчик взял этот стандарт в руки, прочитал и сделал для себя выводы (ага, вот тут мне нужно добавить data атрибут в мою тему чтобы плагины получили нужные данные, тут нужно повесить класс такой-то чтобы к нему привязались сторонние решения и получили нужные данные)
Такое ощущение что завсегдатые разработчики боятся принятия данного стандарта, ведь тогда любой может спокойно выпускать темы поддерживаемыми всеми плагинами без проб и ошибок, без знания особой специфики работы темы default, без танцев с бубном, так ведь?
Про бем, "-Вы не любите кошек? -Вы просто не умеете их готовить."
для вас прочитать и усвоить одну страницу https://ru.bem.info/methodology/quick-start/ это громоздко?
Что такое БЭМ (кратко):
Причем реализация ЛЮБАЯ не нравится вам разделитель __ используйте свой? не нравится рекомендованная структура, используйте свою.
Что все так боятся что то переписать? во первых не переписать а дополнить свои темы классами и data атрибутами, это ведь не долго и много времени не займет.
сейчас и так любой может темы выпускать. Ваш стандарт гораздо сложнее чем дефолт. Никто ничего не боится. Просто это никому не надо! Кстати в темах на основе дефолт у меня плагин прекрасно работает... на остальных криво. Потому как там вообще бардак у всех. Бэм не удобен. Проще уж просто использовать какие то классы для основных элементов.
Похоже просто никто не понял про БЭМ, я как раз и хотел предложить использовать классы для основных элементов но названных не просто из головы, а по стандарттам именования классов БЭМ
тоестэ
s-delivery
s-delivery__error
и т.д.
говно. Не люблю такие непонятные классы. Что за s?
s- означает приложение shop :)
и сейчас уже есть крайне рекомендуемые классы. price, comment и т.д. и айдишники shipping-id ну и тоже так далее
Просто эта рекомендация не озвучена. Но факт, она есть. И ничем не хуже, а семантически так во-многом и лучше, бэм. Но никто не мешает, если хочется, дополнить свою тему любимой методологией.
Повторюсь, почему их не используют плагины а цепляются к li ?? где список этих крайне рекомендуемых классов в документации??
А вот списка-то и нет. И это косячок, да.
Ну вот li#shipping-id- в default. А вы думали, почему у большинства тем чекаут похож? :) Хотя кое-кто, например, смог вообще творчески все переделать и сделать плагин одностраничного оформления доставки и при этом как-то обеспечить совместимость с default.
вам сложно чтоль этому li display:block указать? :)
но примерно, да согласен с вами. Я привык к классам дефолт....
s- - префикс отвечающий что класс специально для скриптов (в Dummy они используется) это отличает его от остальных чтобы не путался, на такие классы не вешаются стилевые формления
delivery - блок
__ - разделитель чтобы четко разделить где блок а где элемент
error - конечный элемент используемого блока
такое разделение позволяет не толкаться локтями с соседними классами и позволяет разделить логику и представление, ну и использовать повторяемость блоком, реализовав один раз логику можно использовать блок в любом месте страницы не боясь что что то поедет
нет. это класс для приложения shop или site. !! причем нестандартный
А чем вас не устраивает Дефолтная структура?
.checkout .checkout-step.step-shipping .checkout-step.step-payment .checkout-step-contentБез проблем, пусть будет стандартом, только почему плагины привязываются к li а не стандартным классам??
li#shipping-id-xxx — можете считать стандартом
И вообще. В default работает. :)
Превелико благодарю)
Может исходя из соображений правильной верстки? Способы доставки/оплаты идут и являются списком...списком. Списком. Понимаете намек? Так то можно весь сайт сверстать используя лишь span+a. Но вы же ставите текстовым параграфам Р, а не div.margin-bottom:20px. А почему тут против логики пошли? Вот поэтому и нужно брать default за основу. Dummy полезна лишь своими *.js. А верстка в ней лишь для того, чтобы увидеть и понять работу этого js.
Считаю надо принять строгое требование к авторам тем, чтобы все страницы были обязательно связаны с моделями Backbone.Js. Мне так удобнее будет взаимодействовать с разными элементами.
Да и всем понравится, только привыкнуть надо
Всем авторам тем разослать предупреждение, что если они не адаптируют свои продукты в течение 14 дней, то продукты будут удалены из каталога вместе с авторами
Надо было подождать пока ТС напишет 20 тем на своем полу-БЭМе, а потом прийти на форум со своими идеями. И ещё желательно методологию какую-то новую применить, чтобы ТС почувствовал на себе.
А пока предлагаю такой вот draft:
ɹǝddɐɹʍ - как вы уже догадались, это у нас wrapper
Ѿ - тоже wrapper, только красивей
ɹǝpɐǝɥ - как вы наверное тоже догадались, это — прекрасный header. Также для header можно использовать это - ☺
ɹǝʇooɟ - а это футер, строго настрого использовать только его без всяких смайлов!
۞ - корзина
‼ - модификатор где все декларации с !important (обратите внимание, что это не два восклицательных символа, а один)
¯\_(ツ)_/¯ - чудо-класс для сообщений об ошибках.
Draft v.0.0.2
ETA: 16.03.2018.
Ѿ это сиськи, а не враппер
Или жопа, в документации так и напишем: "Оборачиваем в жопу".
Если кто-то за БЭМ, то пусть у себя в проектах и использует. Методология хоть и неплохая, но принудительной быть не должна. Прогибать под себя других тоже не надо, потому что: во-первых, тему делаете вы, во-вторых, аккордеон ваш, в-третьих, плагины в инсталлере с тех времен, когда вы ещё не работали с Shop-Script.
P.S. Смотрю на вашу тему. Вы хотите сказать, что ваша мешанина из Bootstrap и БЭМ лучше? Сложилось ощущение, что вы используете БЭМ не потому что он облегчает вам жизнь, а потому что это модно и потому что хипстеры так сказали.
Мы используем из БЭМ только то что нам нужно и только то что упрощает нам жизнь (методология это совершенно спокойно позволяет) не обязательно тянуть полный стек, за модой никогда не гонимся даже наоборот ))
Наверно БЭМ сильно отпугивает, если обозвать не по методологии БЭМ, а по принятым стандартам наименования, так наверно лучше будет?
Почему все видят прогибать кого то под себя?? под стандарты, предложите не по БЭМ если вам так она не нравится! Разве это плохо всегда знать где лежить id-ник службы доставки и куда нужно выводить сообщение об ошибки?
Для следующей разработки берите тему Default.
Не трогайте стандартные классы, добавляете к ним свои БЕМовские, какие вам удобны, переписываете стили под всё это дело.
Зачем нам навязывать вашу любимую методолгию?
Я вот SMACSS люблю и ещё не много Atomic CSS туда примешиваю. И сетку от бутстрапа. Но я же не пишу, что это должен быть стандарт.
Потому что в вашем топикстарте написано, что вы хотите, чтобы были изобретены "новые стандарты", и те программные продукты, которые им не соответствуют должны будут быть удалены. И вам пофигу, что у некоторых разработчиков нет возможности их обновить "прямо к выходу стандарта".
Во первых никто о срока не говорил, срок может быть как угодно долгий
А почему жестко? потому что иначе это не стандарт, а рекомендация, а рекомендацию можно не исполнять.
Вот это и хорошо, что можно не исполнять. :)
Если плагин не соответствует рекомендации -- проблема автора плагина. Если тема -- автора темы.
Насколько я помню в магазине не так уж и много мест, где вообще что-то рекомендовано. (от чего у Гены баттхёрт случился :) ). Страница чекаута одно из таких мест. Зато можно творить с минимальными ограничениями. Ну и вногу себе тоже можно выстрелить, конечно
А почему вы возомнили, что можете решать, что именно будет простой рекомендацией, а что жестким стандартом, из-за не соответствия которому нужно удалять программные продукты?
Ну и чатик развели) https://gitter.im/webasyst-platform/Lobby
БЭМ норм. Для больших проектов и когда надо блоки использовать в разных местах проекта.
Дело то тут не в БЭМ. Может из-за неопытности или наоборот, в силу опыта на более документированных системах тему сделали не совсем так. Придется допилить тему, вариантов нет.
Data атрибуты уже не помогут, всё равно придется тащить классы на которые могут вешаться старые плагины. И вывод только один. Улучшить документацию и примеры.
Как заядлый графоман в плагинописании, в трезвом уме и твердой памяти заявляю, что мне абсолютно пофиг на те темы, которые не укладываются в стандарт Default. Темы стоят очень дорого, и будьте добры соответствовать за эти деньги.
Нет. От input[type=radio][name=shipping_id] никак не избавиться.
Переписал js у единственного своего плагина. выводящего дебильную якарту (тот, кто это ставит себе на сайт, вы с этой якартой с мобильника пробовали справиться?!). Везде, кроме этого radio привязался просто к классам.
без radio не определить, какой метод активен. штатными средствами.
надо будет на досуге еще от jquery избавиться.
А нет. Еще раз посмотрел. Еще select.shipping_rates