Если честно - просто утомила ситуация, когда для того, чтобы изменить вызов какого-то родного компонента на кастомный, приходится дупить пяток шаблонов других компонентов, которые его вызывают, только чтобы изменить этот вызов, а потом тащить их за собой и обновлять ручками. Особенно актуально для КП.
Хочу механизм, который позволит мне переопределить вызов компонента или его параметры, не трогая вызывающие компоненты. Событие тут подходит больше всего.
Может я не прав, переубедите меня.
Я, например, хочу написать обработчик события и вместо вызова компонента bitrix:iblock.vote (голосование, звездочки от 1 до 5) подставлять свой компонент честное голосование
Прямо из маркетплейса одной кнопкой пользователь получит аналогичный функционал, какой у него был, но дополнительно тот функционал, который я добавил: проверку по кукам, IP и ID.
И если у пользователя была многопользовательская фотогалерея с оценками, то он получит фотогалерею с честными оценками.
Да взять тот же набивший оскомину компонент форм в КП, в который уже не первый год просят добавить настройку формы под всех пользователей. Кастомим штатный компонент, пишем пару строк переопределения вызова в обработчике и бац - у нас весь портал с красивыми формами и нужными фичами. Красота же, не?
Плюс лёгкий деплой модификации штатного функционала в МП.
Основные грабли будут с шаблонами штатного компонента (дублирование их в кастомный) + работа в публичке с настройкой компонента (настройки какого вызывать, исходного или подмены, например), но это решаемо и не настолько существенно.
Т.е. в штатном шаблоне какого-то компонента вызывается bitrix:interface.grid, я пишу обработчик и меняю вызов на my_space:interface.supergrid, в котором накручено то, что мне требуется. Не в шаблоне штатного компонента! А в другом, моём, импрувнутом компоненте.
Вызова этих гридов, форм и тп в шаблонах штатных компонентов - умотаться (библиотеки документов, бизнес-процессы, их история, списки, всё это умножаем на два, так как в группах соцсети свои шаблоны для этого функционала, ещё добавляем кучу их использования в CRM - вот почему пример КП).
Другой пример привёл Артемий - iblock.vote, которые в новостях, галереях итп.
А тут мы одним обработчиком, без кастомизации штатных шаблонов и без необходимости дальнейшей поддержки этих кастомизированных шаблонов по приходу их новых обновлений (ну выпустил битрикс обнову, в которой поменял пяток шаблонов, которые опять надо кастомить из-за вызова из них одного компонента), делаем всё, что нужно.
Я, чесгря, не знаю, куда ещё проще.
Два. На что будет переопределяться вызов? На тот же самый компонент, но в котором будет изменено пару строчек? Для своего проекта допустимо, но речь про Маркетплейс? Тогда возникает проблема дублирования коммерческого кода, который Битрикс запретит.
Из этого раз и два пока не видится "вот прям надо". Не, мне не жалко плюса, но я пока занимаю нейтральную позицию. Ибо возможность навредить тоже присутствует.
Про дублирование кода и запрет Битрикса - возможно. Я как-то задавал такой вопрос, внятного ответа не получил.
тоже +, но ногу себе отстрелить можно будет легко
Надо в настройки модуля, использующего данный функционал, выносить возможность быстрого отключения обработчика флажком. Как-то так. Для облегчения диагностики и оперативного пришивания ног.
При разработке решений для маркетплейс бывают такие моменты когда нужно определить вызов компонента и что-то в этом случае сделать. С вот таким событием было бы реально удобнее чем лазить по шаблонам и ковырять их.