Как сделать правильно настраиваемый интерфейс пользователя?

← →
Knight © (2009-07-07 16:53) [0]

Раньше надобности не было, а сейчас надо сделать разные интерфейсы для разных пользоователей, т.е. чтобы если зашёл админ, то появились настройки пользователей, групп и т.п... если пользователь, то убрались какие-то колонки из ListView...

В таком духе. Видимость элементов должна быть описана в базе и привязывается к группам администратором.

Как это делается более гибко?

← →
Knight © (2009-07-07 16:56) [1]

Т.е. "Элементы должны быть описаны в базе и их видимость привязывается к группам администратором."

← →
Knight © (2009-07-07 16:57) [2]

И реализовать это надо за 2 дня :)

← →
clickmaker © (2009-07-07 17:06) [3]

> Элементы должны быть описаны в базе и их видимость привязывается
> к группам администратором

ну если на примере колонок листвью, то
table ListColumns
ColumnId Name Title

table UserColumns
UserId (или GroupId) ColumnId Visible

А вообще "настройки пользователей, групп и т.п" - это же элементы UI, которые отображают некоторые сущности? Вот к этим сущностям и разграничивать доступ.
Можно по такой схеме. Есть таблица со сквозным Id, которая представляет все сущности программы, и Id в которой удобно привязывать к списку доступа.
Типа
EntityId UserId AccessLevel
а есть отдельные таблицы для отдельных сущностей со своим Id и своими полями, но которые связаны с основной по EntityId.
Ну а дальше - дело техники )

← →
Игорь Шевченко © (2009-07-07 17:45) [4]

> И реализовать это надо за 2 дня :)

Сколько ?

← →
Хитрий Лис (2009-07-07 19:37) [5]

Я бы поставил вопрос иначе - Нужны ли админу юзерские данные? - и написал бы отдельного клиента для админки...

← →
Дмитрий С © (2009-07-07 20:03) [6]

Таблица привязки прав к группам:
AccessRuleId
GroupId
AccessAction

И таблица возможных прав
AccessRuleId EntityType EntityId ComponentName

AccessRuleId - ключевое поле таблицы прав.
GroupId - это группа, которой разрешено или запрещено.
EntityType - тип сущности, например Вкладка, Колонка или отдельный Edit.
EntityId - строка идентифицирующая сущность. Например, номер колонки или вкладки.
ComponentName - компонент, для которого это действо затевается. Например, TForm1.ListView1
AccessAction - два значения Можно/Нельзя.

На мой взгляд это весьма "залипушно", но за 2 дня сделать не трудно будет :)

← →
Knight © (2009-07-07 21:21) [7]

Добрался таки до компа :)

Всё прочитал... спасибо за советы. Надо обмозговать.

← →
Knight © (2009-07-07 21:22) [8]

> [4] Игорь Шевченко © (07.07.09 17:45)

Сколько ?

← →
Kolan © (2009-07-08 13:03) [9]

Можно использовать метафору перспектив как в Эклипсе, то есть:
1. Описать объекты, которые знают как надо настроить UI для каждого типа пользователей.
2. Запрограммировать контроллер (или кто у вас всем заправляет) так, чтобы он узнавал тип пользователя в базе, создавал и применял нужную перспективу.

Еще если «...надо сделать разные интерфейсы для разных пользоователей...» — советую прочесть про миф о дихотомии «новичок-эксперт».

> «новичок-эксперт»

Надо разграничить не по принципу опыта работы, а чтобы каждый видел то, что требуется по работе и не видел, того, что ему без надобности и даже вредно :)

Удалено модератором

Knight, это я на всякий случай сказал, потому что есть опасность уйти в сторону и подумать, что админ — опытный пользователь, который и так во всем разберётся.

Как сделать правильно настраиваемый интерфейс пользователя? Найти похожие ветки