Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Voprosy-otvety_k_gosekzamenu_CKOT_1.doc
Скачиваний:
11
Добавлен:
25.02.2016
Размер:
1.91 Mб
Скачать
  1. Именование элементов дизайна при разработке приложений в Domino Designer.

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

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

Для извлечения и вывода информации из базы данных предназначены формы. По умолчанию, когда форма создается и сохраняется, ее название автоматически добавляется к меню Create приложения, что дает возможность пользователям до-бавлять данные в базу данных, используя меню приложения. Пусть, скажем, у вас имеется приложение для контроля за сервисными запросами потребителей. Обоз-начение формы как «Service Request» («Сервисный запрос»), а не «Form А» («Фор¬ма А») окажется более осмысленным и понятным с точки зрения пользователя. Для подачи запроса пользователь просто выберет в меню пункт Create > Service Request (что куда очевиднее, чем Create > Form A).

В дополнение к первичному названию элемента можно задать необязательный псевдоним - синоним, используемый как ссылка, ведущая к тому же самому эле-менту. Рекомендуемая практика разработки гласит: при создании приложений баз данных Notes псевдоним должен создаваться всегда. Это обеспечит большую гиб-кость при изменениях, позволив не затрагивать код, представления, агенты и дру¬гие составляющие приложения. В отличие от первичного названия элемента псев¬доним обычно не появляется в интерфейсной части клиента.

Вернемся к примеру сервисного запроса, в качестве псевдонима которого мож¬но выбрать строку «SR». Псевдоним будет ссылаться на другие элементы дизай¬на базы данных Notes. Например, скажем, что приложение (или база данных) для работы с сервисными запросами содержит несколько форм и вы хотите получить представление, отображающее лишь сервисные запросы. Для создания представ-ления к нему требуется добавить формулу выборки, которая позволит вывести на экран только документы-запросы. Указанная здесь формула может ссылаться на первичное название «Service Request» или «SR», если псевдоним задан. При задан-ном псевдониме формула выборка представления должна ссылаться на псевдоним. Применение псевдонимов - рекомендуемая практика разработки.

ПРИМЕЧАНИЕ

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]