Комментарии 3
Спасибо, интересно. У себя в проекте не используем tv вообще. А какие советы если используются свои таблицы в базе.
Пожалуйста.
1. Связанные объекты. Чтобы было легче обращаться к связанным объектам, например так: $extProfile = $modx->user->ExtProfile;
2. Целостность данных. Вообще правильно рулить целостность данных на уровне базы данных, оперируя вторичными ключами, но у xPDO свой подход на уровне php, поэтому нам придется использовать именно его. Не буду сейчас вдаваться в подробности какие именно там подводные камни. Так вот, логично, что если это расширенный профиль для пользователя, то при удалении пользователя этого расширенного профиля не должно оставаться, то есть он должен автоматически удаляться при удалении объекта пользователя.
Вам наверняка известно, что для этого достаточно прописать правила этих связей в мап-файлы. Но проблема в том, что нам связь по сути нужна не только из кастомного объекта, но и из системного. А файлы ядра мы не можем трогать. Вот тут мы тоже можем использовать озвученный в статье механизм, чтобы дописать эту связь для класса modUser.
Вот такая связь и решает эти две проблемы. То есть вы в любом месте можете выполнить $modx->getObject('modUser', $id)->remove(), и вместе с пользователем удалится и запись из вашей кастомной таблицы.
А какие советы если используются свои таблицы в базе.А никаких особенно нет советов. Там все стандартно для любого проекта. Вот только разве что aggregates/composites-связи. Простой пример: вот вы, к примеру, добавили какой-то свой дополнительный класс для пользователей (соответственно с таблицей). К примеру это extUserProfile. Здесь есть два основных момента:
1. Связанные объекты. Чтобы было легче обращаться к связанным объектам, например так: $extProfile = $modx->user->ExtProfile;
2. Целостность данных. Вообще правильно рулить целостность данных на уровне базы данных, оперируя вторичными ключами, но у xPDO свой подход на уровне php, поэтому нам придется использовать именно его. Не буду сейчас вдаваться в подробности какие именно там подводные камни. Так вот, логично, что если это расширенный профиль для пользователя, то при удалении пользователя этого расширенного профиля не должно оставаться, то есть он должен автоматически удаляться при удалении объекта пользователя.
Вам наверняка известно, что для этого достаточно прописать правила этих связей в мап-файлы. Но проблема в том, что нам связь по сути нужна не только из кастомного объекта, но и из системного. А файлы ядра мы не можем трогать. Вот тут мы тоже можем использовать озвученный в статье механизм, чтобы дописать эту связь для класса modUser.
$this->map['modUser']['composites']['ExtProfile'] = array(
'class' => 'ExtUserProfile',
'local' => 'id',
'foreign' => 'internalKey',
'cardinality' => 'one',
'owner' => 'local',
);
Вот такая связь и решает эти две проблемы. То есть вы в любом месте можете выполнить $modx->getObject('modUser', $id)->remove(), и вместе с пользователем удалится и запись из вашей кастомной таблицы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расширение системных (и не только) таблиц в MODX Revolution