Войти
 
 
   
 
  
Новости 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

Стандарты проектирования и разработки приложений на платформе Lotus Notes. Окончание

Владислав Шубников, ведущий разработчик, г.Днепропетровск

Стандарты проектирования и разработки приложений на платформе Lotus Notes

Начало материала >>>

Раздел 4. Создание форм

Основные требования при создании форм

1. Не создавать форм, если смысл документа и все процессы по нему не ясны!!! Выяснить у постановщика задачи все неясные моменты, и только тогда приступать к разработке!

2. Следствие из п.1. - желательно, чтобы названия форм-документов были на русском языке и точно соответствовали названию документа!
Не использовать псевдонимы, если названия формы и реального документа совпадают!

3. Можно создавать группированное название формы через прямой слэш (/), например: "Справочник/Документ об образовании", в названии формы (на нашей стандартной подформе "Свойства") будет выведено только значение после слэша.

4. В поле "Комментарий" на свойствах формы должно быть описано её назначение (если это непонятно из названия формы): желательно правильно называть форму, чтобы смысл был понятен без описания.

5. В заголовке форм документов (Window Title) обязательно прописывать следующие строки:
@If(@IsAvailable($UpdatedBy);
@If(Form="Название своей формы"; <<Формула для заголовка окна, чаще всего просто Form>>; "(УДАЛЁН)");
"Новый документ")

6. Всегда на формах, по которым создаются реальные документы, размещать изменяемое поле Form, в которое прописывать название формы в значении по умолчанию(!)
Если документ создаётся методом Compose, то поле (свойство) Form появляется только после сохранения документа.
Этим обходятся ошибки, которые встречаются в противном случае (до сохранения документа):

  • иногда требуется обновить RTF-поле, при переоткрытии документа он открывается по "Форме по умолчанию";
  • при обращении к значению Form в новом документе, оно возвращает пустую строку.

7. Формы, насыщенные информацией, упаковывать в таблицы на вкладках, название вкладок - по смыслу.

8. Названия (под)форм, используемых для вывода диалоговых окон, должны быть сконструированы по шаблону: Dialog_смысл.
Все диалоги желательно делать в подформах, убирать в них галочки:

  • Использовать в построителе запросов - DbSearch будет работать быстрее;
  • Выводить в окне вставки подформ - чтобы не мешали при выборе.

9. Названия форм, используемых для рендеринга, должны быть сконструированы по шаблону: Render_смысл.

10. Названия форм, используемых для печати, должны быть сконструированы по шаблону: Print_смысл.

11. При использовании вычисляемых подформ, их названия должны быть составлены таким образом, чтобы их можно было вычислять - это избавит от ненужных IF'ов.
Пример: для подгрузки различных подформ родительского и ответных документов формула для подформ будет выглядеть так: "SubformName#"+@Text(@IsResponseDoc).
Наименование соответствующих подформ вполне понятно из формулы.

12. На коде обработки событий форм/подформ желательно не использовать глобальные UI-объекты (NUID_Current, ND_Current), описанные в разделе 3. Исключение составляют объекты, использующиеся и в форме и подформах одновременно. В таких случаях инициализировать их из Source as NotesUIDocument, а ни в коем случае не из NotesUIWorkspace

Раздел 5. Создание полей

1. Поля выполняющие одну ту же функцию должны иметь одинаковые названия во всех формах.
Пример: поле PersonCode, в других формах, которые будут наследовать информацию из данного документа, должно называться PersonCode, а не Person_Cod, PCode и т.д.
Желательно, чтобы название одних и тех же по смыслу полей было одинаковым во всех БД, поэтому необходимо договариваться с другими разработчиками, возможно у нас уже есть и используются в базах поля с аналогичным смыслом.

2. Принцип формирования названий полей: группировка по назначению(!) - <Назначение><Зарезервированый суффикс>
Примеры группировки:

Наименование поля

Назначение (к чему относится)

AuthorAdr
AuthorName
AuthorDuty
AuthorHierarcy

Реквизиты автора

InitiatorAdr
InitiatorName
InitiatorDuty
InitiatorHierarcy

Реквизиты инициатора контроля

CompanyFullName
CompanyShortName
CompanyUNID

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

3. Зарезервированые суффиксы:
Суффикс
Назначение полей
Примеры
Описание
Adrимя в системеAuthorAdrИмя в системе автора
Nameобычное ФИОManagerNameФИО менеджера
DutyдолжностьVizirDutyДолжность визирующего
HierarcyоргструктураCuratorHierarcyОрг. структура куратора
CodeкодыCurrencyCodeКод валюты
NumberномераOrderNumberНомер заказа
DateдатыPayDateДата платежа
UNIDUNID'ыVizirUNIDUNID карточки визирующего лица
4. Предусматривать возможность вычислять в скрипте названия полей.
Например, комплект полей из документа "Работа" в БД "Производство":
PreQuant
PreCost
PreBill
PlanQuant
PlanCost
PlanBill
FactQuant
FactCost
FactBill
назван так чтобы производить универсальные (общие для каждой из строк) вычисления. Названия полей разбиваются на составные части, например, Quant, Cost, Bill (показатель столбца) и Pre, Plan, Fact (показатель строки), и двумя параметрами передаются в одну-единственную функцию, которая производит определённые вычисления для переданной комбинации, т.е. фактически для определённой строки таблицы по вычисленным столбцам.

Стремиться к тому, чтобы однородные поля состояли из одинакового количества символов, например, размер названия PlanQuant и FactQuant одинаков; это позволит по размеру префикса/суффикса программно разбивать эти названия на составные части и определять по полученным частям строку/столбец, в которых нужно производить вычисления. С этой точки зрения поле PreQuant лучше было бы назвать PrevQuant, чтобы префикс тоже состоял из 4-х символов, как Plan и Fact.

5. Создавать поля на формах (в Designer'e) в основном нужно, если эти поля являются обязательными для интерфейса; для Item'ов, вписываемых с помощью NotesDocument.ReplaceItemValue() можно использовать вычисляемый текст. Для облегчения обновления полей при изменении их значений в режиме для чтения вместо Computed Text лучше использовать CFD-поля.

6. Если в форме используются скрытые поля (поля создаваемые из скрипта), то необходимо в конце формы привести таблицу следующего вида, если поле скрыто на форме вставить его в 1-ю колонку таблицы.
Пример:

SourceDB

Наименование БД, откуда инициирован платеж

Status

Статус:
На подготовке
На согласовании
Снят с контроля
Отклонен
Согласован
Оплачен, не закрыт
Оплачен, закрыт
Оплачен, проведен

Fin

"-1" - расход, "+1" - приход

Manual

1 - документ создан с нуля, т.е. вручную из БД "Платежи"
0 - на основе документов-позиций из других БД

Props

0 - запретить отображение Фин. реквизитов;
1 - разрешить;
2 - фин. реквизиты уже заполнены

Side

0 - Внутренний (расчёт между отделами одной организации) - нулевой. - диалог фин. реквизитов не выводится.
1 - Внешний (расчёт между организациями)
Признак, проводить по счетам или нет!

Confirmators

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

7. В полях типа ComboBox, DialogList, RadioButton желательно использование псевдонимов в виде "числовых" значений.
Это полезно для полей-статусов и др., для значений которых планируется программный анализ. Удобство "числовых" значений в таких полях заключается в том, что формулы отбора представлений, вычисляемых текстов и самое главное - формулы скрытий(!) можно писать с учётом возможности использования арифметических сравнений, т.е. не просто 'равно' или 'не равно', а и 'больше', 'меньше' и т.д. - это повышает динамику (возможности функционала) и в общем облегчает разработку баз данных.

Раздел 6. Создание действий

1. Панель действий и сами действия должны быть оформлены (цвета и проч. на 3-й вкладке свойств панели действий) в стиле текущей БД!
У нас, за редким исключением, это системный цвет.

2. Шрифт надписей должен быть MS Sans Serif, 8 (устанавливается в свойствах панели действий).

3. На действие/группы действий обязательно должна быть установлена иконка!
Для стандартных действий использовать стандартные иконки:

ДЕЙСТВИЕ

ИКОНКА

ПРИМЕЧАНИЕ

Перейти


Должно быть оформлено как группа действий, с отображением только иконки.

Печать


только иконка

Поиск


только иконка

Поместить в папку



Очистка


Например, очистка текущей папки

Создать документ


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

Справочник


Пополнение справочников

Запись в календарь


только иконка

Отправить почту



Отправить документ куда-либо



Утвердительная форма


Например: "Согласовать"

Форма отказа


Например: "Отклонить согласование"

Указание


Назначение лица на выполнение чего-либо

Обозначение какого-либо действия или процесса


Используется для группы действий

Можно использовать как "Выполнено"


для процессов кроме выполнения контроля "Исполнение"

Перекачка данных из одного документа в другой

или


Уход документа из текущего вида


Например, при изменении статуса (чаще всего уход обратно, к предыдущему статусу)

Вычисления



Блокировка или установка/изменение доступа


только иконка

Этих иконок обычно хватает. Если присутствуют нестандартные операции, то иконки подбирать по смыслу, а не лишь бы что.

4. Случаи использование действий типа Menu Separator:

  • по назначению (для разделения действий горизонтальной чертой в группе действий, разворачивающихся как меню);
  • для визуального разделения (в дизайнере) действий с разным выравниванием (по правому/левом краю), 'Menu Separator' должен быть между ними;
  • для предотвращения скрытия панели действий если в виде используется опция 'Evaluate action for every document change', т.е. когда действия скрываются от определённых значений полей документов вида.

5. Программный код общих действий (SharedActions) желательно выносить в агенты, которые в зависимости от задачи либо контекста запускать из действия с помощью @Command([ToolsRunMacro]; "имя агента") либо NotesAgent.Run.

Раздел 7. Создание представлений

Основные требования при создании представлений:

1. Названия представлений, которые будут выводиться на экран, писать по-русски. Если к представлению необходим доступ из скрипта, то нужно пользоваться его псевдонимом (Alias), который указывается на английском языке.
Для представлений, выводимых в аутлайнах и использующихся в Page и FrameSet'ах псевдоним обязателен! Выполнение этого требования исключает необходимость перекодировки из Base64 при работе с XML.
Основные интерфейсные представления (наиболее часто используемые) желательно именовать большими буквами по-русски, – т.о. эти представления можно быстро найти в Designer'е в общем списке представлений.

2. Псевдонимы скрытых представлений, используемых для поиска или диалогов, желательно делать вычисляемыми, т.к. это избавляет от лишних IF'ов.
Пример: SelectEntries#-1
Наименование SelectEntries - (выбор статей) - информативно;
-1 - значение поля Fin (определяет расход/приход), т.е. если текущий документ расходный, то автоматом откроется вид по расходам.
Факторы для вычисления можно использовать любые, НО(!) необходимо помнить, что лучше использовать уже готовые представления и не размножать их по пустякам (создавать только по необходимости), т.к. представления занимают большую часть от общего объёма БД и довольно сильно определяют характеристику производительности сервера (нагружая задачу Indexer).

3. Все скрытые представления должны быть снабжены комментарием, описывающим назначение данного представления.

4. Следить за пробелами между словами и правописанием.

  • не называть представления с цифр;
  • группировать представления через прямой слэш (/), псевдонимы представлений можно через # или _
(использование прямого слэша связано с уходом от преобразования в двойной обратный слэш при вызове из LS @-формул @DbColumn, @DbLookup и др.)
  • название каждой группы должно начинаться с большой буквы
Пример названия вида: Рабочий план/Текущее состояние/По оргструктуре

5. Колонки представлений.

  • Заголовки колонок в видах центрировать.
  • Шрифт для заголовков колонок (и в самих колонках) должен быть MS Sans Serif, 8. Форматирование желательно не использовать, выдерживать общий стиль баз данных комплекта.
  • Обязательно выяснять и устанавливать соответствующий тип данных в колонках
Например, для числовых значений (сумм) необходимо:
  1. 2 знака после запятой;
  2. выравнивание по правому краю;
  3. установка разделителя групп разрядов (тысяч);
  4. цвет цифр в колонке должен совпадать с их цветом (поля) на форме – это наглядно и вообще очень удобно для пользователя.
Аналогично устанавливать формат отображения дат.
  • Если значение, выводимое в колонке-категории, не заполнено (не обязательное к заполнению), то в ней необходимо выводить надпись по следующему формату:
"! Значение ... не указано !".
"! Область не указана !".

Раздел 8. Создание агентов

1. Стандарт наименования агентов:
<Элемент дизайна откуда произв. запуск>-<Наименование элемента дизайна>#<Объект, откуда произв. запуск>-<Наименование объекта>
Элементы дизайна, использующиеся в названиях:
- Form;
- SubForm;
- View;
- Folder;
- SharedAction.
Объекты, использующиеся в названиях:
- Action;
- Button.
Для возможности выгрузки агентов в XML без предварительной обработки обратный слэш (\) в наименованиях заменяем на дефис (-).
Примеры наименований:
Form-Заказ#Action-В отменённые
SharedAction-Исполнение

2. Создавать агенты только полностью выяснив его особенности запуска: права и периодичность, если агент по расписанию.

3. Помня о проблемах при обновлении агентов (замена дизайна + репликация на др. сервера): код, так сказать, особо ответственных агентов выносить в библиотеки!

4. В комментарии к агенту указывать расписание выполнения агента (для агентов, выполняемых по расписанию) в формате:
~5 - означает, что агент запускается каждые 5 минут;
3:00 - агент, запускается ежедневно в 3:00;
2:00 25.01.xxxx - агент отрабатывает в 2:00 ежегодно 25 января.
После указания расписания через дефис может идти краткое описание агента.
Данное правило формирования комментария позволяет наглядно видеть расписание для всех агентов базы.

Благодарности
Автор выражает признательность разработчикам, которые в период 2001 - 2004 гг. "стояли у истоков" этих стандартов: Станиславу Волнянскому, Сергею Гудимову, Владимиру
Кирилину
Автор благодарит Ника Норкина за редактирование, корректировку и размещение материалов на сайте

Начало материала >>>

Читайте на Notesnet.ru:
Десять заповедей по разработке приложений >>>
 
  Опубликовано — 07/09/2007 |    

Vlad Sh, 04.12.2008:
Хех! Опять по поводу расширенного синтаксиса. Я писал по поводу ReplaceItemValue... Мой новый коллега, Дима Пастовенский, по поводу GetItemValue на больших циклах (в сотни тысяч) доказал обратное - dot-синтаксис медленнее на 15-25%. Получается, что для ReplaceItemValue dot быстрее, а для GetItemValue dot медленнее. Ещё интересные факты: GetNthDocument, в цикле из тысяч итераций, как минимум в 6 раз медленнее GetNextDocument. Если увеличивать цикл, то GetNthDocument замедляется приблизительно в арифметической прогрессии. Ещё Дима показал интересный класс StringBuffer на LS (с http://www.nsftools.com), который конкатенацию строк выполняет, как минимум, в 100 раз быстрее! Ссылка на исследование по сравнению производительности методов конкатенации: http://www.nsftools.com/blog/blog-10-2007.htm#10-12-07



Добавить комментарий
Имя * :
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