Отправляет email-рассылки с помощью сервиса Sendsay

Создаем свой бизнес

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Секреты бизнеса. Предприниматели рассказывают..." на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Июль 2003   →
 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
Автор
Людмила Лунькова

Статистика

12.222 подписчиков
-21 за неделю
←   Все выпуски   →

Создаем свою информационную систему


Информационный Канал Subscribe.Ru

Создаем свою информационную систему

Декорирование и режимы работы документа

Про режимы работы я уже как-то пытался писать, напомню что это значит.

 

Режим работы документа. Режим работы документа – это то, как он виден на различных рабочих местах. Действительно, в зависимости от стадии жизненного цикла документ может выглядеть совершенно по-разному. Например, инструкция на стадии разработки  имеет один вид и свойства, на стадии утверждения доступен раздел утверждений и комментариев, но не доступен для редактирования основной раздел текста. На стадии исполнения инструкция доступна только для чтения, но возможно внесение комментариев. Все это режимы работы одного и того же документа.

 

Здесь главное слово «виден» оно говорит о том, что на разных местах документ действительно выглядит по-разному.  Но одно дело сказать, а другое дело реализация.

Какими же возможностями мы обладаем в текущей версии системы?

 

Поскольку в широком смысле до реализации методов документа на уровне интерфейса пользователя мы не дошли. То, у нас есть только возможность управлять видимостью разделов и видимостью полей на формах редактирования. Управлять мы можем еще на уровне описания модели. Что это значит? А значит, это буквально следующее в описании модели документа есть такие характеристики, как режим работы. Режим имеет имя, и для того чтобы открыть документ в нужном режиме надо передать это имя в качестве параметра:

 

on error resume next

If ID <> "" Then

    Dim Obj As Object

    Set Obj = item.Manager.GetInstanceObject(ID)

    If Not Obj Is Nothing Then

      Dim objGui As Object

      Set objGui =  item.Manager.GetInstanceGUI(Obj.ID)

      If objGui Is Nothing Then Exit Sub

      objGui.Show "<ИМЯ РЕЖИМА!!!>", Obj

      Set objGui = Nothing

    End If

End If

 

Ясно, что только имени в описании мало, есть еще система ограничений, которая говорит о том какие разделы и поля ограничены по доступу.

Есть два типа ограничений (если исключить ограничения на методы):

  1. Ограничения на видимость разделов
  2. Ограничения на поля (поле отсутствует, нельзя изменять поля)

 

Обращаю внимание, что режим работы и права на совершение операций две совершенно разные вещи. Например, вы можете не видеть какого-то раздела, но теоретически иметь права на проведение над ним операций. Эта ситуация очень часто возникает, когда нам надо организовать нестандартное отображение для некоторых разделов. Яркий пример – описание бизнес процесса. Мы не видим явно раздела, который описывает список функций процесса и их связи, но имеем право редактировать эти разделы и спокойно редактируем. Поэтому, режимы работы – это именно средство декорирования, а не средство ограничить права на изменение.

С другой стороны, мы можем легко запретить группе пользователей открывать документ в некоторых режимах. Это уже возможность, встроенная в функциональность интерфейсной части документа. Она просто не даст вам открыть документ, если доступ ограничен.

 

Теперь основной вопрос. Как реализованы режимы?

Ясно, что вопрос реализации режимов, это вопрос об алгоритме работы генератора кода, который будет смотреть на модельную информацию и создавать исходные тексты. Вся реализация режимов сосредоточена в генераторе кода, который создает приложение пользователя. Фактически, генератор работает так, как будто он создает все контрольные элементы и формы редактирования для режима первый раз. Т.е. для каждого режима работы документа будет сформирован свой набор контрольных элементов и форм редактирования. Более того, в текущей реализации все эти объекты размещаются в одной физической объектной библиотеке. Строя формы редактирования, генератор просматривает ограничения для конкретного режима и устанавливает на форму только те контрольные элементы, которые в этом режиме присутствуют. Так же он поступает, когда выкладывают корневые разделы документа на вкладки основной формы. Ясно, что если раздел верхнего уровня запрещен к просмотру, то и все его дочерние разделы тоже запрещены и не будут даже создаваться.

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

 

В последующих версиях мы безусловно решим обе эти проблемы, но пока они остаются.

 

Теперь у нас осталась еще одна, последняя альтернатива, которая впрочем, была всегда.

Ручная модификация сгенерированного кода с целью изменения поведения документа (строки раздела и т.п.)

 

Этот способ декорирования есть смысл применять на более поздних стадиях, когда уже начала появляться уверенность в стабильности модели документа. Ясно, что бывают ситуации, когда  этот момент не наступает очень долго, а демонстрировать систему надо. Остается смириться с ситуацией, и использовать возможности, которые предоставляют практически все программы для хранения исходных текстов (SourceSafe и т.п.) – сравнение файлов, которые были исправлены вручную и файлов, которые получены при очередной генерации документа.

 

Общие подходы к декорированию определили, теперь пора посмотреть, как это смотрится в реальном документе… но уже в следующем выпуске.

Ведущий рассылки: Михаил М. Баранов
bami@murometz.spb.ru www.murometz.spb.ru Кубики для взрослых
http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное