PHP Inside

 
   
 

Главная


Начало
страница1
страница2
страница3
страница4
страница5
страница6
страница7
страница8
страница9
страница10
страница11
страница12
страница13
страница14
страница15
страница16
страница17
страница18
страница19
страница20
страница21
страница22
страница23
страница24
страница25
страница26
страница27
страница28
страница29
страница30
страница31
страница32
страница33
страница34
страница35
страница36
страница37
страница38
страница39
страница40
страница41
страница42
страница43
страница44
страница45
страница46
страница47
страница48
страница49
страница50
страница51
страница52
страница53
страница54
страница55
страница56
страница57
страница58
страница59
страница60
страница61
страница62
страница63
страница64
страница65
страница66
страница67
страница68
страница69
страница70
страница71
страница72
страница73
страница74
страница75
страница76
страница77
страница78
страница79
страница80
страница81
страница82
страница83
страница84
страница85
страница86
страница87
страница88
страница89

 
 
 

 

 

При функционировании надстрой­ ки потребуется косвенное управле­ ние большим количеством вспомо­ гательных объектов ( объекты ти­ пов «Комната ожидания» (UserMove WaitingRoom), «Стул ожидания» (User MoveChair), «Ссылка на стул ожида­ ния» (UserMoveChairLink). Все эти объ­екты являются исключительно вспомо­ гательными , и менеджеру по персона­лу ничего не нужно знать о них , чтобы пользоваться надстройкой . Вся низ­ коуровневая работа ложится на сце­ нарии . Однако эти сценарии будут вы­ полняться от имени пользователей ( ру­ ководителей отделов ). Для эффектив­ ной работы менеджерам необходимо предоставить полный доступ ко всем вспомогательным объектам .

Так , чтобы поставить сотрудни­ ка в очередь перемещения из одно­ го отдела в другой , менеджеру необ­ ходимо модифицировать содержимое комнат ожидания обоих подразделе­ний . То есть опять получается ситуа­ ция , что для перевода человека ме­ неджеру по персоналу требуются осо­ бые полномочия как в отделе - источни­ ке , так и получателе . Это практически сводит на нет все преимущества над­ стройки и предоставляет широкие воз-


можности для злоупотреблений . Бо­ лее тонкое распределение полномо­ чий , если и возможно , то является до­ статочно сложным процессом . А чем выше сложность , тем больше потен­ циальных дыр .

Я решил остановиться на бо­ лее простом и эффективном реше­ нии . Вся работа со вспомогательны­ ми классами концентрируется на сер­ вере . Рассмотрим основные преиму­ щества подхода .

•  Сценарии на стороне клиента вы­
полняют только минимальный объ­
ем операций , сводящихся к подго­
товке и отправке команды серверу .
Для выполнения всех действий не­
обходимы только права управления
объектами в одной организацион­
ной единице .

•  Все операции по реальному пере­
мещению пользователей выполня­
ются на сервере с правами админи­
стратора , что позволяет избежать
необходимости разработки слож­
ной ( а значит , более подвержен­
ной ошибкам ) системы распреде­
ления прав к вспомогательным объ­
ектам .

На стороне клиента формирует­ ся команда ( начать , подтвердить или отменить перемещение ), которая со­ храняется в виде объекта в организа­ ционной единице менеджера по пер­соналу . Серверная часть надстройки ожидает событий появления таких ко­манд . Когда это происходит , команда выполняется , если прошла проверку на допустимость .

Для реализации этого механизма потребуется создать дополнительный класс команды . Пусть он называется UserMoveCommand. Установим необ­ходимые атрибуты . Во - первых , пона­ добится собственно идентификатор команды . Вот список команд , необхо­ димых для управления надстройкой


( идентификатор будет принимать од­ но из этих значений ).

•  StartMove - начать перемещение
пользователя .

•  Accept - подтвердить перемеще­
ние пользователя . Завершает пе­
ревод сотрудника в целевой от­
дел .

•  Deny - отказать пользователю в пе -
ремещении . Отказ в приеме со­
трудника .

•  RollBack - отмена операции пере­
мещения . Сотрудник возвращает­
ся в исходный отдел .

Также потребуется атрибут для хра­ нения идентификатора пользователя - объекта команды и того , кто команду создал (executor).

Рассмотренных атрибутов доста­ точно для команд подтверждения пе­ ревода пользователя (accept) и отмены операции (rollback), так как они завер­ шают процесс перемещения . Коман­ да отказа приема пользователя (deny) ставит перемещаемый объект в ком­ нату ожидания исходного подразде­ ления . Для нее потребуется дополни­тельное поле с комментарием , содер­ жащим причину отказа .

Самой сложной является коман­ да начала перемещения (StartMove). Во - первых , она должна содержать всю необходимую информацию для пос­ тановки объекта пользователя в оче­ редь перемещения ( комментарий , вре­ мя , инициатор операции , пункт назна­чения , включена или отключена пере­ мещаемая учетная запись ). Во - вторых , команда начала перемещения должна быть контейнером , содержащим поль­ зователя . То есть выносимый сотруд­ ник будет отключаться и помещаться «внутрь» объекта команды , как бы ис­чезая из стандартных оснасток .

Рассмотрим результирующую схе­ му классов , необходимую для реализа­ ции надстройки ( см . рис . 1). Отметим , что к названиям всех реальных клас­ сов и их атрибутов будет добавлен пре­ фикс UserMove, чтобы избежать слу­ чайных совпадений имен с системны­ ми объектами .

Итак , организационная единица (organizationalUnit) может содержать объекты классов комнаты ожидания (WaitingRoom) и команды (Command). Также , естественно , она может со­держать и объекты пользователей ,