про поле thread_id и не только

VictorSmirnov 28.10.2003 11:04

Предлагаю рассмотреть сл. ситуацию.
У нас есть объект parent и у него
два потомка child1 и child2.

Верно ли, что у этих объектов должен
быть общий thread_id?
Подозреваю, что да.

Тогда, для определения доступов к объекту
child2 мы вытаскиваем доступы к объекту child1
(и всем его потомкам, не так ли), что нам совершенно
не нужно.

Возможно, что в каком-то узле дерева объектов
поле irf будет равно 0, тогда нам, очевидно, не нужны все
его предки.

Получается, что нужно писать весьма сложный
код для создания параметра thread перед вызовом метода
@getRightsToObject[object;thread;acl;is_owner].

На всякий случай замечу, что к приведеному коду
у меня претензий нет, потому как это всего лишь пример.

Мне представляется, что проще в классе auth определить
виртуальный метод getObject[object_id], который
бы выдавал нужные поля объекта в удобном виде.
Например, таблицей. Виртуальный, потому как в
общем случае, в классе auth, как я понимаю, мы
не знаем, что такое объект и откуда его брать.
Дальше, в коде метода getRightsToObject[]
вместо обращения к таблице thread можно поставить
вызов метода getObject. Поле acl тоже не нужно,
его можно получить по объекту.

В таком случае, использование класса упрощается.
Нужно только создать наследника класса и определить
простой метод getObject. Это, думаю, намного проще,
чем вытаскивать всех предков, не забывая при этом
про поле irf. Тем более, что все предки могут
и не понадобиться. Например, в случае, когда у нас
уже "закэшированы" права на одного из предков, скажем, непосредственного.

Мне очень понравилась идея провести аналогию с NDS.
Бросаются в глаза отличие.
В NDS пользователи и группы тоже являются объектами.
И на них можно давать права!

Спасибо за внимание!

---