Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Всё о задаче AdminP. Часть вторая   Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть
О Notes Читать статью
 
Всё о задаче AdminP. Proxy-действия в R5 и Domino 6   Приложение к статье об административном процессе
О Notes Читать статью
 
Всё о задаче AdminP. Часть первая   Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Динамический отбор документов в представления

Николай Норкин,
Вятские Информационные Технологии, Киров
В материале продолжается рассмотрение вопросов, связанных с проектированием представлений, начатое в предыдущей статье "Динамические представления" (Перейти>>>). На этот раз автор постарается ответить на вопросы, связанные с попытками разработчиков добиться большей гибкости от проектируемых представлений. К сожалению, зачастую прямой дороги нет, приходится пользоваться обходными путями.


1. Проблемы, связанные с проектированием представлений
Одни из самых важных элементов дизайна баз Notes - это представления (views) и папки (folders). Посредством представлений пользователю отображается реестр отобранных и организованных в нужном порядке документов.
При относительно небольшом количестве документов в базе эргономика и степень проработки интерфейса базы данных не критичны и не бросаются пользователям в глаза, поскольку оные минуют уровень представления быстро, считав необходимую информацию либо осуществив переход к конкретному документу.
Однако, при увеличении количества документов, правильное проектирование представлений становится все более значимым и отражается на производительности труда пользователя. От разработчика может потребоваться включить в строки представления, соответствующие документам, дополнительную информацию, акцентировать внимание пользователя на конкретных документах либо предоставить тому самому сформировать запрос на отбор документов.

2. Общие правила
Представления, возвращаемые в ответ на пользовательский запрос, не что иное как динамические индексы, создаваемые по правилам, заданным в элементе дизайна, и поддерживаемые в актуальном состоянии задачей Indexer, выполняющейся на сервере (для представлений, хранящихся на сервере) или в составе клиента Notes (для приватных представлений, хранящихся на клиенте). Логика правил, по которым индексер подготавливает индексы, обеспечивает высокую производительность задачи, но, вместе с этим, накладывает свои ограничения

Правило №1. Реестры документов базы данных могут быть организованы в виде представлений (views) и папок (folders). Отбор документов в представления происходит на основе определенной при проектировании дизайна представления формуле (View selection formula). Отбор документа в папку осуществляется с помощью событий помещения и удаления документов из нее. Иными словами, наполнение вида определяется дизайном БД, а наполнение папки - пользователями или внешними, по отношению к системе, событиями.
Правило №2. В формуле отбора представления, а также в формулах колонок ограничена возможность использовать информацию, не хранящуюся в самих документах. И, как следствие, невозможность использования формул @GetProfileField, @DbLookup, @GetDocField, @Responses и т.п.
Правило №3. Представления и папки бывают общими (shared) и личными (частными, приватными, private). С общими представлениями работает большинство пользователей базы. Этот момент следует учитывать при рассмотрении дальнейших возможностей "динамизации" представления по запросу пользователя. Личные представления могут храниться как на сервере (непосредственно в базе), так и на стороне клиента (в desktop.dsk - локальные представления). Первый случай требует дополнительных ресурсов сервера (объем базы растет за счет хранящихся индексов представлений для каждого пользователя, поддержка индексов также требует ресурсов). Во втором случае нагрузка по поддержке индекса представления ложится на рабочую станцию
Правило №4. Для поддержания актуальных индексов представлений требуются ресурсы сервера(или рабочей станции). По этой причине задача индексирования может не успевать обрабатывать изменения, влияющие на содержание представлений, в реальном времени или не замечать этих изменений.

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

View Selection и переменные окружения
В языке @-формул имеется набор функций, позволяющих читать и задавать значения пременным окружения, хранимым в файле Notes.ini(Notes Preferences для Macintosh)): @Environment, @SetEnvironment, and ENVIRONMENT.

В документации по разработке Domino 5 Designer Help сказано, что данные функцию нельзя использовать в формулах отбора или колонках представлений: @Environment cannot be used in column or selection formulas... Но, как показывает практика, они работают.
Использование переменных окружения связано с определенной спецификой: индексы представлений, хранящихся на сервере, используют переменную окружения из серверного файла настроек notes.ini (За исключением случаев, когда управляющий или разработчик базы перестраивает представление в клиенте, используя комбинацию клавиш Shift+F9 - тогда используется значение переменной со станции. Этот момент важно учитывать и быть поосторожнее при перестроении этих представлений).Личные представления, хранящиеся на станции, используют переменную из клиентского notes.ini и с ними не возникает проблем. Трудности возникают именно при работе серверных представлений. Первая из них - как пользователю задать значение переменной в серверном файле Notes.ini, - снимается достаточно легко. Еще со времен третьей версии Notes автору известно решение, основанное на отправке почтового сообщения в mail-in базу с последующей его обработкой серверным агентом на приход новой почты. В версии Lotus Notes/Domino 4.6 появилась возможность выполнять агента в пользовательской сессии на сервере (метод RunOnServer) и проблему можно считать окончательно решенной. Вторая трудность заключается в том, что в ряде решений подобный подход входит в противоречие с тем фактом, что общие представления предназначены для использования не одним человеком, а несколькими. Трудно спрогнозировать, что увидит каждый из этих пользователей, когда они все вместе начнут менять значения переменных окружения.

Создание личных представлений, хранящихся на клиенте, (десктопных представлений) решит обе проблемы....Правда, останутся другие. Связанные с производительностью решения, обусловленные Правилом №4.

Показания:

  • Использование в "слабо-динамических" представлениях с динамикой изменения переменной окружения "раз в сутки".
  • Использование в общих представлениях, где изменять переменную окружения может только один пользователь (менеджер), все остальные используют для чтения.
  • Использование переменной окружения, изменяемой серверным агентом.
    Примеры:
  • Прайс-лист, в котором "рублевые" цены рассчитываются на основании содержащихся в документе "у.е." и курса валюты, который хранится в переменной окружения и изменяется серверным агентом раз в день.
  • Отбор документов в представление на основании определенных условий, не запрограммированных жестко в формулу отбора представления.

    Folders vs. Views
    В Правиле №1 говорилось о различии между папками и представлениями. Основное достоинство использования папок - возможность отбора документов по достаточно гибкой логике, что невозможно для представлений (Правило №2).

    "Динамические" папки
    Программный код (LotusScript или Java) во время своего исполнения производит отбор документов базы и на основании этого отбора помещает полученную коллекцию документов в SPOFU-папку (Shared, private on first use), которая затем программно открывается пользователю. При закрытии папки (в процедуре обработки события QueryClose папки) документы удаляются из папки
    Недостатки и преимущества данного метода были описаны в свое время Олегом Таранченко в форуме компании Интертраст (Как результаты программного FT-поиска отобразить в виде...).

    Недостатки:
    1. Изменение наполнения общей папки видно всем пользователям. Чтобы этого избежать можно использовать частные папки. При использовании папок общих, становящихся частными при первом использовании (наиболее привлекательный вариант) следует иметь в виду, что "приватизация" папок не может быть выполнена программно - пользователь должен это сделать вручную. Это можно рассматривать как bug, но факт - эта особенность характерная всем версиям Notes в том числе текущим 5.0.x
    2. Документы в папке с точки зрения Notes есть просто набор документов, а не результаты поиска. Это приводит к тому, что теряется информация о релевантности отдельных документов и чтобы обеспечить сортировку по этому критерию, нужно заводить специальное поле, его заполнять при помещении в папку и т.д. Неудобство очевидно.
    3. При помещении документа в папку производится обновление внутренней структуры папки, определеющей ее содержимое. Эта процедура занимает время, незаметное для 1-2-3-... документов, но значительное для десятков и тем более сотен. Вплоть до того, что поиск шел секунду, а наполнение папки минуты.

    Преимущества:
    1. Приобретается возможность пересортировывать документы всеми необходимыми задаче способами, предусмотрев их в дизайне папки. В версиях до R5 для "нормальных" результатов FT-поиска это невозможно.
    2. Не требуется "внешнего" программирования

    Стоит отдельно рассмотреть вопрос про необходимость сохранения информации о релевантности документов. В разработке под Notes стоит остерегаться массового (как и лишнего, ничем не обусловленного единичного) пересохранения документов.

    Рекомендации
    • Использование для отбора документов по запросу пользователя
    • Использование в решениях, предоставляющих пользователю для полнотекстового поиска в базе "прикладную" форму для ввода параметров запроса

    "Статические" папки
    Метод пригодится, когда условие отбора документов остается неизменным, однако разработчик сталкивается с ограничениями, налагаемыми невозможностью выразить это условие на языке @-формул. Часто встречающийся пример такой задачи - отбор документов по наличию ответных к ним документов-потомков или значению в этих потомках:("Как сделать так, чтобы показывались только те родители с ответами, у которых поле документа ответа больше определенного значения?")

    При сохранении документов (в рассматриваемом примере - ответных документов) удовлетворяющий условию родительский документ помещается в папку (а неудовлетворяющий, соответственно, удаляется из нее). Аналогичным образом оформляются все прочие события, влекущие изменение в "состоянии" родительского документа (удаление ответного документа, перепривязка его к другому родительскому документу и т.п.). Для подстраховки можно написать агента, который будет запускаться периодически и выполнять проверку условий отбора в папку. Также, следует запретить добавление/удаление документов в/из папки вручную пользователем.

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

    К сожалению, даже такой гибкий механизм отбора документов, как папки, имеет свою "ахиллесову пяту". Речь идет о папках, поддерживающих иерархию ответов (с включенной опцией Отображать ответные документы в виде иерархии). В этом случае действие добавления в папку (удаления из папки) применимо только к главному документу, вместе с которым добавляется (удаляется) все дерево привязанных к нему ответных документов-потомков. Принцип все или ничего может стать препятствием для решения некоторых задач

    Embedded View with single category
    Об использовании встроенных представлений для показа списка документов, отобранных по определенному критерию (категории) автором было рассказано в предыдущем материале (Перейти>>>), в данном материале демонстрируются примеры решений.

    Как показать пользователю список документов, соответствующих выбранной дате.
    В форме документа размещается поле выбора даты или java-апплет с той же функциональностью и встроенное представление, первый столбец которого категоризирован по дате (создания, изменения, утверждения, поставки на контроль или/и т.п.). Формула раздела Show single category использует значение поля даты.

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

    Отбор документов по дате определенного действия над документом. Показать пользователю список документов по дате определенного действия (создание, изменение, утверждение, оплата, отгрузка, постановка на контроль и т.п.), при этом предоставить ему выбрать дату и действие самостоятельно из списка.
    Формула категоризированного столбца будет задавать комбинацию из даты и действия, что соответствующим образом скажется на увеличении индекса представления

    Domino R6: функция @SetViewInfo
    В справке разработчика (Domino Designer 6 Help) дан следующий пример использования функции @SetViewInfo:

    @SetViewInfo([SETVIEWFILTER];@Name([CN];@UserName);"employeeName";1)

    К сожалению, у автора нет информации о возможности применения этой функции для решения подобных задач. Представляется, что одним из вариантов ее использования будет размещение ее в коде события открытия представления или в коде кнопки панели действий


    4. Ссылки по теме
    Как отобразить документы, в полях которых указан текущий пользователь
    Как обновить дизайн папки (folder), в том числе SPOFU?
    Как удалить из базы приватные представления, хранящиеся на сервере

    Опубликована первая часть статьи Проектирование представлений
    Читайте также:
    Java-апплет: альтернатива встроенному представлению >>>
     
      Опубликовано — 05/13/2003 |    



    Добавить комментарий
    Имя * :
    e-mail
    Комментарий * :
    Код подтверждения * :


  • Мероприятия
    Пресс-релизы
    Биржа труда
    Последнее на форуме
     
    А так же:
    Как удалить профиль?
    16.04.2016 00:08:51
    Скопировать в буфер поле документа
    24.05.2015 08:55:52
    Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
    16.04.2015 16:49:58
     
    © LOGOSPHERE.RU