Fi1osof 09 сентября 2014 0 0
Все-таки, иногда в 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, который содержит данные этого объекта, но это все-таки не объект.
0 комментариев
Авторизуйтесь или зарегистрируйтесь (можно через соцсети ), чтобы оставлять комментарии.