А всего-то — маленькая доза. Решил сделать проверку на то, имеет ли пользователь возможность просматривать свойства объекта или нет. И если нет — выводить ошибку. Так как это пригодится еще много где, решил вставить этот функционал (правильнее, наверное, «метод») прямо в класс самого объекта.
После генерации схемы и модели для работы со своими таблицами в базе, я получил файл, в котором мой новый объект описывался так:
class Calls extends xPDOSimpleObject {}И я мог делать со своим объектом все, что хотел — то есть, getObject, getCollection, newObject, get, set…
А тут взбрело в голову дописать функционал прямо в класс:
class Calls extends xPDOSimpleObject { function checkAccess(){ $creatorId = $this->get('created_by'); $creator = $this->xpdo->getObject('modUser', $creatorId); $accessGroup = $creator->get('primary_group'); $currentUserId = $this->xpdo->getLoginUserID(); $currentUser = $this->xpdo->getObject('modUser', $currentUserId); $currentUserGroup = $currentUser->get('primary_group'); if ($accessGroup != $currentUserGroup) { die("<h1>Error</h1><p>You don't have permission for this Call.</p>"); } } }
И теперь на странице, где отображается информация об этом объекте я пишу просто
$call->checkAccess();и если пользователь не имеет права просматривать информацию, он увидит ошибку.
Это обалдеть можно! Я в полном восторге! Я могу буду дописывать логику по проверке доступа к объекту (добавлю проверку не только по группе пользователя, но и проверку личного доступа к конкретным данным конкретного пользователя), нормально оформлю отображение ошибки и теперь буду стараться как можно больше логики выносить именно в классы.
P.S. Отдельное спасибо за это просветление Николаю /> за тот поток информации, который он нам дал на недавней встрече клуба MODX. Именно этот поток информации бурлил у меня в голове почти неделю и, наконец, структурировался и дал мне сильный толчок, чтобы разобраться с ООП. G+
Оригинал статьи community.modx-cms.ru/blog/9697.html
1 комментарий