В форме заказа сайта (sale.order.ajax) необходимы JavaScript-обработчики событий для реализации дополнительных действий. Часто возникает необходимость выполнять доп. методы при определенных действиях. Например:
Кроме того, наличие этих обработчиков позволило бы реализовать ряд тиражных модулей.
- при выборе точек самовывоза.
- при нажатии кнопки "Далее в том или ином блоке.
Кроме того, наличие этих обработчиков позволило бы реализовать ряд тиражных модулей.
Данных в событии не хватает для нормальной обработки.
В случае, если стреляет событие на добавление комментария или даже апдейт задачи - в обработчике не имеем даже ID задачи, не говоря про остальное.
В то же время выше вызова обработчиков событий имеем массив $message, в котором имеется вся необходимая информация и даже больше. Только вот в событие отправляется только куцая и местами бесполезная его часть.
Желательно отправлять в обработчик сам $message, а не $message['EVENT_DATA'].
Схожая идея пятилетней давности -
В случае, если стреляет событие на добавление комментария или даже апдейт задачи - в обработчике не имеем даже ID задачи, не говоря про остальное.
В то же время выше вызова обработчиков событий имеем массив $message, в котором имеется вся необходимая информация и даже больше. Только вот в событие отправляется только куцая и местами бесполезная его часть.
Желательно отправлять в обработчик сам $message, а не $message['EVENT_DATA'].
Схожая идея пятилетней давности -
Нужно событие, которое действительно "Финальное" в обмене с 1с. И это событие происходит после деактивации.
//Final step
elseif ($_GET["mode"]=="deactivate")
...
foreach (GetModuleEvents("catalog", "OnFinalDeactivateCatalogImport1C", true) as $arEvent) {
ExecuteModuleEventEx($arEvent, array($arParams));
}
|
У нас в веб-студии есть определененный стандарт: все обработчики хранятся в модулях в папке lib/eventhandlers/<код модуля, чье событие обрабатывается>.php
Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой:
\Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin
Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.
Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?
Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой:
\Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin
Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.
Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?
Имеется ввиду что-то типа OnAfterBackupCreate. Данное событие было бы полезно для разработчиков, чтобы отследить, например, делался ли когда-то бэкап (если он в последствии был удален), или при автоматическом резервном копировании совершать какие-либо действия после создания бэкапа, например отсылать на почту уведомления или что-то подобное
При обновлении из списка элементов и из страницы редактирования элемента пользовательские свойства имеют разный формат.
Например, свойство типа "Список".
Со списка передается
array(
0 => "",
1 => SOME_VALUE,
)
а со страницы редактирования элемента
array(
0 => array(
"VALUE" => SOME_VALUE ,
)
)
При отсутствии значения в первом случае передается
array(
0 => "",
)
Во втором ничего не передается.
Очень трудно под эту логику навесить свою логику.
Например, свойство типа "Список".
Со списка передается
array(
0 => "",
1 => SOME_VALUE,
)
а со страницы редактирования элемента
array(
0 => array(
"VALUE" => SOME_VALUE ,
)
)
При отсутствии значения в первом случае передается
array(
0 => "",
)
Во втором ничего не передается.
Очень трудно под эту логику навесить свою логику.
Хотелось бы, чтобы в админке появилась такая чудесная страница, которая показывала бы отчет по обработчикам событий. Под отчетом я понимаю:
1 Тип события
2 Модуль, к которому относится событие
3 Список обработчиков событий (в том порядке, в котором будут вызываться)
3.1 Название класса и метода/функции-обработчика
3.2 Расположение класса и метода/функции-обработчика (полный путь к файлу, номер строки)
3.3 Признак системности (установлен модулем или разработчиком в init.php)
1 Тип события
2 Модуль, к которому относится событие
3 Список обработчиков событий (в том порядке, в котором будут вызываться)
3.1 Название класса и метода/функции-обработчика
3.2 Расположение класса и метода/функции-обработчика (полный путь к файлу, номер строки)
3.3 Признак системности (установлен модулем или разработчиком в init.php)
В файле /bitrix/modules/main/classes/general/event.php:227 заменить это
вот на это
Такое решение даст возможность через обработчик OnBeforeEventSend запрещать отправку писем определенных почтовых событий при определенных условиях, заданных разработчиком.
$events = GetModuleEvents("main", "OnBeforeEventSend");
while ($event = $events->Fetch())
ExecuteModuleEventEx($event, array(&$arFields, &$db_mail_result_array)); |
$events = GetModuleEvents("main", "OnBeforeEventSend");
while ($event = $events->Fetch())
if(ExecuteModuleEventEx($event, array(&$arFields, &$db_mail_result_array)) === false)
return "F"; // Fail |
Необходимо добавить два обработчика событий:
Они должны вызываться для всех существующих init.php: общего и сайто-зависимых.
Зачем это необходимо
добавление кода в init.php может преследовать две цели:
1. Добиться подключения кода на каждом хите т.е. расширение его области видимости. С последующим вызовом из произвольного места на сайте. Т.е. подключение кода и его вызов разнесены во времени исполнения страницы.
2. Добиться подключения кода и его работы непосредственно сразу после подключения.
В обоих случаях код добавляют руками. Если необходимо раздавать код, который работает по принципу 2 (подключили и тут же запустили) через маркетплейс, то это становится трудоёмкой задачей. Нужно писать инструкцию.
Пример такого кода - класс для логирования. Он обслуживает код, который уже исполняется в init.php, а обработчики событий ещё не начали работу. Посмотрите на .
В маркетплейсе появились решения которые уже дописывают свой код в хвост init.php я считаю, что обработчики решат эту проблему.
Добавлять строчку в шапку init.php с вызовом CModule::IncludeModule('MyModule');
Руками разработчика или скриптом считаю не очень хорошей идеей.
OnBeforeIncludeInitPHP OnAfterIncludeInitPHP |
Зачем это необходимо
добавление кода в init.php может преследовать две цели:
1. Добиться подключения кода на каждом хите т.е. расширение его области видимости. С последующим вызовом из произвольного места на сайте. Т.е. подключение кода и его вызов разнесены во времени исполнения страницы.
2. Добиться подключения кода и его работы непосредственно сразу после подключения.
В обоих случаях код добавляют руками. Если необходимо раздавать код, который работает по принципу 2 (подключили и тут же запустили) через маркетплейс, то это становится трудоёмкой задачей. Нужно писать инструкцию.
Пример такого кода - класс для логирования. Он обслуживает код, который уже исполняется в init.php, а обработчики событий ещё не начали работу. Посмотрите на .
В маркетплейсе появились решения которые уже дописывают свой код в хвост init.php я считаю, что обработчики решат эту проблему.
Добавлять строчку в шапку init.php с вызовом CModule::IncludeModule('MyModule');
Руками разработчика или скриптом считаю не очень хорошей идеей.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
