Все-таки, иногда в MODX-е встречаются вещи, которые меня заставляют негодовать, мягко говоря. К примеру вот эти два метода:

modObjectCreateProcessor::fireBeforeSaveEvent()
 
   public function fireBeforeSaveEvent() {

        $preventSave = false;

        if (!empty($this->beforeSaveEvent)) {

            /** @var boolean|array $OnBeforeFormSave */

            $OnBeforeFormSave = $this->modx->invokeEvent($this->beforeSaveEvent,array(

                'mode'  => modSystemEvent::MODE_NEW,

                'data' => $this->object->toArray(),

                $this->primaryKeyField => 0,

                $this->objectType => &$this->object,

                'object' => &$this->object, // for backwards compatibility, do not use this key

            ));

            if (is_array($OnBeforeFormSave)) {

                $preventSave = false;

                foreach ($OnBeforeFormSave as $msg) {

                    if (!empty($msg)) {

                        $preventSave .= $msg."\n";

                    }

                }

            } else {

                $preventSave = $OnBeforeFormSave;

            }

        }

        return $preventSave;

    }

И modObjectUpdateProcessor::fireBeforeSaveEvent()

public function fireBeforeSaveEvent() {

        $preventSave = false;

        if (!empty($this->beforeSaveEvent)) {

            /** @var boolean|array $OnBeforeFormSave */

            $OnBeforeFormSave = $this->modx->invokeEvent($this->beforeSaveEvent,array(

                'mode'  => modSystemEvent::MODE_UPD,

                'data' => $this->object->toArray(),

                $this->primaryKeyField => $this->object->get($this->primaryKeyField),

                $this->objectType => &$this->object,

            ));

            if (is_array($OnBeforeFormSave)) {

                $preventSave = false;

                foreach ($OnBeforeFormSave as $msg) {

                    if (!empty($msg)) {

                        $preventSave .= $msg."\n";

                    }

                }

            } else {

                $preventSave = $OnBeforeFormSave;

            }

        }

        return $preventSave;

    }

Заметили как много "отличий" у этих методов? То есть как минимум можно было один метод на оба процессора сделать общим. Но главная соль вот в этой строчке:

'object' => &$this->object, // for backwards compatibility, do not use this key

В create- процессоре она есть, а в update- процессоре ее нет. Уточню, что это ключ массива данных, передаваемых в массив $scriptProperties, доступный в навешиваемых плагинах. При этом они еще и советуют этот ключ не использовать, и используйте типа ключ$this->objectType.

Вот у меня вопрос? Зачем так усложнять? Почему было не оставить тупо элемент object? Дело в том, что в случае когда у нас object, тогда мы не паримся и не задумываемся будет этот объект или нет. Это всегда объект, с которым будет выполняться сохранение. А вот в случае с $this->objectType нам совершенно нет гарантий какое именно название будет у этого объекта. Спросите зачем его вообще кому-то может понадобиться менять? А вот иногда надо. Простой пример - лексиконы. Может понадобиться изменить тип объекта, чтобы изменить выводимые системные сообщения, ведь там все на лексиконах, к примеру:

public function logManagerAction() { $this->modx->logManagerAction(

    $this->objectType.'_update',

    $this->classKey,

    $this->object->get($this->primaryKeyField));

}

И вот пишу я тут "универсальный" плагин на апдейт, и не знаю, будет там ключ resource, или будет какой-то другой. И главное - нельзя обратиться к процессору и "поинтересоваться", а кокой это тип объекта и как к нему обратиться...

Вот такая фигня... Есть только вариант обратиться к элементу data, который содержит данные этого объекта, но это все-таки не объект.