Добавить обработчик события подключения модуля
Событие после подключения модуля - OnAfterModuleInclude.
Давно уже мучает такая мысль, что часто это было бы удобно для подключения своего функционала, связанного с модулем и местами позволило бы избежать лишнего кастома и замусоривания init.php. Например по событию инклюдить файл со своими дополнительными к модулю функциями, которые используются в шаблонах.
К тому же это позволит не заморачиваться подключенностью модуля, если собственные функции/классы обращаются или унаследованы от модуля.
Всё мучался мыслью а-ля module_epilog.php, но тут увидел предыдущую идею и подумал, что событие удобней.
Или все используют автозагрузку?
Давно уже мучает такая мысль, что часто это было бы удобно для подключения своего функционала, связанного с модулем и местами позволило бы избежать лишнего кастома и замусоривания init.php. Например по событию инклюдить файл со своими дополнительными к модулю функциями, которые используются в шаблонах.
К тому же это позволит не заморачиваться подключенностью модуля, если собственные функции/классы обращаются или унаследованы от модуля.
Всё мучался мыслью а-ля module_epilog.php, но тут увидел предыдущую идею и подумал, что событие удобней.
Или все используют автозагрузку?
© 2001-2022 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
Думаю, большинство для этого используют автолоадер и не заморачиваются.
Например
расширяем \Bitrix\Sale\Internals\Input\Base
и хотим чтобы этот класс имел публичный метод который будет собственно и регистрировать наш пользовательский тип. (в котором будет \Bitrix\Main\EventManager::getInstance()->addEventHandler(......))
Пробуем обратится к этому методу, на что получаем что class \Bitrix\Sale\Internals\Input\Base не найден.
Не спорю, можно и не делать в рамках этого класса регистрацию пользовательского типа, но мало ли, кому то может и так удобно