Количество плагинов и тем дизайна растет. Их уже не пересчитать по пальцам. Взаимодействие плагинов с темами дизайна становится довольно тесным, в связи с чем начинают возникать проблемы с интеграцией. Разработчики тем создают свои классы, свои идентификаторы, оформляют скрипты по-своему.
Для того, чтобы интегрировать плагин в тему, необходимо для каждой темы создавать свою подробную инструкцию, потому что абстрактную смогут понять далеко не все пользователи. Это не нормально. Как пример: https://igaponov.ru/docs/76/se... и https://igaponov.ru/docs/77/ou...
Предлагаю Вебасисту разработать правила, которые должны соблюдать все разработчики при создании своих тем дизайна.
Что может быть в этих правилах?
- Обязательные классы и ID для блоков, с которыми часто взаимодействуют плагины: летающие корзины, цены в летающих корзинах, блок со итоговой ценой, блок со скидкой, блок оформления/корзины в одностраничном оформлении и тд. Список может быть большим, но он упростит в дальнейшем всем жизнь и будет гораздо легче работать с темами.
Если у всех будут одинаковые классы на отдельных блоках, можно будет сделать системную функцию в JS, которая сможет динамически обновлять лишь эти блоки. Удобно же. Собрать от всех плагинов запросы на обновление блоков и одним разом их актуализировать. Похоже сделано у CS-Cart, но это отступление.
- События в JS: события добавления товара в корзину, удаления товара из летающей корзины, обновления летающей корзины, изменения артикулов, количества, начало/окончание ленивой подгрузки. Действий тоже может быть много, но они по большей части простые и одинаковы для всех тем. В события обязательно нужно передавать класс измененного блока и избыточные дополнительные данные (цена, скидка, текст и тд).
- Инструкции по работе с формами: если форма изменена, нужно сделать так, чтобы обязательно произошло событие изменения. Например, изменили кол-во через "плюсик", обязательно вызови событие trigger('change') для поля количества. Имеются ввиду такие случаи.
- Именование переменных Smarty. Образно, сейчас встречаются и $products, и $_products, и $_hey_my_awesome_theme_products. В связи с этом сложно направить пользователя, где и что ему искать.
- Обязательные шаблоны. Иногда становится проблематичным найти, где же расположен тот или иной блок. Не нужно ограничивать в создании шаблонов, я предлагаю лишь создать список обязательных, где можно сразу найти вывод товаров, цену товара, блок со скидками, бейджи и тд.
Сейчас есть тема Дефолт и негласное правило: "Если плагин работает на дефолте, значит проблема в теме дизайна". Многие разработчики переносят ID и классы из этой темы. Но так делают не все. Надеюсь, Вебасист сможет навести порядок и внести ясность в процесс разработки продуктов.
10 комментариев
Интересное правило. Я вот знаю другое. Для плагинов в системе предусмотрены хуки. И в темах они все обычно есть. Если плагин требует ручной интеграции, то нужна....ручная интеграция, для которой требуется определенная квалификация. И если её нет, то её обладатели найдутся в каталоге экспертов или на бирже проектов ВА. А вот умалчивание о необходимости ручной интеграции считаю попыткой наебать.
Вопрос не в smarty хуках, а в именовании классов и идентификаторов у html блоков. Откуда вы взяли про "умалчивание ручной интеграции" я не понял. Тема о другом.
Проблема в том, что плагин не может ни за что гарантировано зацепиться в теме. Например, есть блок с итоговой ценой. Как в JS файлах плагина поймать его во всех темах?
Еще пример, есть одностраничное оформление, есть блоки #js-order-form и #js-order-cart - в той теме Дефолт, которую я привел как "эталонную". В этих блоках хранится информация о "контроллерах" страницы оформления. Большинство тем дизайна использует такие же идентификаторы. Как плагину получить данные этих контроллеров? Обратиться к указанным выше ID: $('#js-order-form').data('controller').
Что произойдет, если все станут устанавливать свои идентификаторы (сегодня столкнулся именно с такой проблемой в одной из популярных тем)? Плагин не сможет работать в большинстве тем, либо в плагине нужно предусматривать разные наименования. Согласны, что в текущих условиях и данном случае Дефолт служит примером?
Да. И что? Я лишь говорю о том, что подобные плагины требуют ручной интеграции. Проблема тут лишь в том, что под это всё нельзя написать единую и понятную инструкцию, чтобы её поняла секретарша. Ну так может не стоит секретарше лезть в код? Не зря же существует проверенная поколениями поговорка: "Не электрик - не##й лезть".
Со стороны клиента да, это выглядит странно. Сначала купи, а потом плати, чтобы заработало. Но им вполне можно объяснить устройство мира. Мол по техническим причинам универсального способа интеграции в любую тему сделать невозможно. Только в виде kit'a. Если у вас нет квалификации и вы не хотите обращаться к экспертам за интеграцией, значит этот продукт не для вас. Есть куча людей, для которых это не проблема. Для них продукт и создан. BodySite вон на всех подобных плагинах прямо пишет, что для внедрения требуется навык разработчика. Как бы... если я куплю новый V12 от Бентли, то за его установку я буду платить еще кучу денег. Ну или своими силами, если у меня есть знания и навыки техника. И это воспринимается всеми нормально.
Ну ты же сам понимаешь как устроен этот мир. Отрисованные дизайнером макеты верстает верстальщик, который не знает и не обязан знать работу всех плагинов. Его задача сверстать. Классы он обзывает как хочет. Если бы была какая-то инструкция от ВА с обязательным списком функциональных классов, то может и можно было бы верстальщику дать ссылку на неё в ТЗ к вёрстке. Но это не решит проблему. Плагины зачастую модифицируют контент, к которому цепляются. И разметку заставлять делать одинаковую? Плюс темы с каждым годом всё сложнее и замороченнее. Всего не предусмотреть. Сегодня напишешь одни правила, а завтра разработчики по обе стороны придумают что-то новое, что не вписать в эти правила.
Это я как человек, который бывал по обе стороны конфликта. И kit-плагин был и тема. И я никогда не позволял себе обвинять разработчика темы в том, что он использовал класс не из Default, к которому плагин цепляется, а свой собственный(разве что из-за отсутствия стандартного хука мог поругаться). А вот от тебя, Игорь, пару раз приходили люди со словами "Нам сказали, что вы тупой и тема ваша говно. Ибо вы не сделали в ней обязательного для плагина Х класса" :) Оперировалось тогда той же логикой "Если в дефолте работает, а у вас нет, значит проблема в теме". Любопытно, но вот в других темах от ВА тоже не работает. Посмотри ту же Dummy и не найдешь там привычных классов. А вебасист рекомендовал именно её брать за основу для разработки своих тем. Получается что... Разработчики плагинов игнорируют рекомендации, из-за которых им придется что-то переделывать и просят ввести другие рекомендации, чтобы другие переделывали. Так себе позиция.
Единственный более менее выход из ситуации с недовольными клиентами, который мне видится, это дополнительное разделение плагинов. На плагины и Kit'ы.
Я не про ручную интеграцию, я же привел два примера, когда, зная имена классов и идентификаторов, можно изменять контент везде, а не лезть в тему, подставлять свои классы, которые затрутся при обновлении. Из-за того, что темы становятся сложными, каждый раз лезть и менять их становится проблемой для всех, потому что обновление сложной темы требует полного сброса настроек.
Сейчас, разрабатывая продукт, я просматриваю первые 50 тем, чтобы подстроиться под их классы (про разметку речь не идет), чтобы у клиента не было проблем. Это по вашему нормально?
Я не считаю попытку стандартизировать некоторые моменты в разработке "так себе позицией" и не сподвигаю все предусмотреть. Я за то, чтобы из всего выделить ключевые моменты, от которых нельзя отходить. Недавний мой опыт с одностраничным оформлением, который я описал, наглядное подтверждение. Вот там я точно не ожидал, что будут изменены идентификаторы.
почему в плагинах не сделать настройку просто, указать класс к которому цепляться, большинству плагинов это пойдет, проблема будет решена, я так в своих плагинах и сделал
Согласен, это может быть решением, чтобы зацепиться, но это также усложнит работу с плагином, если блоков будет десяток.
Разработчику все равно придётся либо перекопать множество тем, чтобы найти эти блоки, либо не переживать и приготовиться к наплыву вопросов в поддержку.
Я сейчас не имею ввиду конкретных продуктов и за основу беру абстрактные плагины для глубокой работы с витриной.
К сожалению, это не решит проблему событий в js.
Я привёл часть моментов, которые на мой взгляд нужно привести в порядок. Список можно расширить.
Я также понимаю, что любое изменение устоявшихся укладов может вызывать недовольства и негодования.
да согласен, что для сложных плагинов это не подойдет
но разработчикам тем, реально откуда знать, какие плагины используют какие классы, плагинов то тьма
плюс бывает структура такая, что ее еще под плагин менять приходится, очень не удобно
Я так сделал и спустя время пришел к выводу, что лишь небольшое количество пользователей в состоянии самостоятельно разобраться как правильно выдернуть из своей темы дизайна нужный селектор и вставить его в настройки плагина.
Полностью поддерживаю идею от Игоря Гапонова. А вот с Евгением Леман категорически не согласен.
- Дак Игорь как раз и предлагает решение, которое бы значительно снизило необходимость в интеграции плагинов. Если предложенные идеи будут внедрены, у "секретарши" вообще не будет перед глазами инструкции по интеграции, т.к. плагин будет работать без нее.
- Если речь о верстальщике, который разрабатывает тему дизайна для дальнейшей публикации в маркет WA, то он как раз-таки обязан знать принципы работы популярных плагинов и, имея требования по наличию в теме дизайна тех или иных классов, обязан их соблюдать. Не вижу в этом абсолютно никаких проблем, если WA сделает простую и наглядную инструкцию по наименованию классов. Пусть разработчик темы создает классы какие хочет и верстает как хочет, но также дополнительно обернет каждый блок системными классами согласно документации. Делов минут на 30? 40? Это затраченное время полностью отобьется уменьшением нагрузки на ТП.
---
Со стороны эта дискуссия выглядит как спор между человеком, заинтересованным с тем, чтобы система развивалась, и человеком, который привык пользоваться несовершенством системы, извлекая из этого личную выгоду в виде проведения платных доработок по ручной интеграции плагинов и обновлений тем дизайна (и не хочет терять лакомый кусочек).
4 года прошло) https://developers.webasyst.ru... а воз и ныне там
Для себя сделали выводы - что webasyst ничего менять не будет/не желает/не может
Они лучше придумают свой кастомный UI 2.0 который никто не знает, чем возьмут что-то популярное и известное, например bootstrap, не нравится bootstrap - пожалуйста, есть tailwind (стильно, модно, молодежно)), но нет мы потратим кучу сил и усилий на свое, родное ) чем внедрим какие-то стандарты и регламентируем взаимодействие частей системы - ведь стандарты, это так скучно, а вот свой UI 2.0 - это так круто