Когда в D7 нужны события на добавление, а когда надо переопределять родительский метод

Антон Долганин 7 Декабря 2015 15:46 4817

Поделюсь своим имхо на этот счет. Предполагаю, что вы уже знаете что такое D7, и организацию обработчиков событий там.

Допустим, у вас есть таблица, D7-класс к ней, в котором добавление стандартизировано. Ну к примеру - перед добавлением надо проверять наличие некоторых полей, или всегда переопределять одно поле, или, как в примере ниже, проверять не добавлялся ли такой элемент в сессии уже. В общем, редко, но такие задачи бывают. Вариант? Написать обработчик.

Но я предлагаю еще вариант в таких случаях - переопределять родительский add. Примерно так:

use Bitrix\Main\Entity; //за классом

public static function add($fields)
{
   $hash = md5(serialize($fields));
   if (!isset($_SESSION['IH_CONVERSION_ITEMS'])) {
      $_SESSION['IH_CONVERSION_ITEMS'] = array();
   }
   if (in_array($hash, $_SESSION['IH_CONVERSION_ITEMS'])) {
      $result = new Entity\AddResult();
      $result->addError(new Entity\EntityError('Уже был похожий элемент за сессию.'));
      return $result;
   } else {
      $_SESSION['IH_CONVERSION_ITEMS'][] = $hash;
      return parent::add($fields);
   }
}

$res = \IHB24\ConversionTable::add(array('OBJECT_ID' => 1, 'SECTION_ID' => 3, 'CONTEXT_ID' => 3));
var_dump($res->getErrorMessages());
 //string(62) "Уже был похожий элемент за сессию."

Как видите, нам абсолютно все равно, как устроен родительский метод, мы делаем проверки и отправляем исполнение ему, если это разрешено. Первичной проверкой мы экономим ресурсы, так как не затрагивается родительский метод в большинстве случаев, мы не отказываем себе в использовании "штатного" add.

Комментариев: 2

Алексей

8 Декабря 2015 16:11

Здраво

Ссылка

Антон Долганин

21 Декабря 2015 13:19

Пример использования http://blog.d-it.ru/dev/ins-ignore-bitrix-d7-and-lazy-programmer/

Ссылка