Что делает настройщик

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

На MS SQL-сервере создана база данных DbExample,
В BDE создан псевдоним alDbExample для этой базы данных,
В базе данных DbExample нет ни одной системной таблицы и ни одной пользовательской таблицы.
В памяти созданы все необходимые списки. Пока мы знакомы со списком таблиц FTablesList и списком имен таблиц FTableNames компоненты TDbInterface, а также с обобщенным списком FFbSUObjectL элементов СУ компоненты TArmInterface. На самом деле создается значительно большее число списков. Однако нам важно пояснить принцип работы платформы, поэтому обойдемся необходимым минимумом. Более менее полный список рабочих списков, используемых в платформе, можно найти в прилагаемом учебном приложении.

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

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

На Рисунок 1 показано, как выглядит один из ключевых моментов запуска штатной системы.

Рисунок 1

В этих условиях существует лишь одна возможность продвинуться вперед – продолжить загрузку в режиме конфигуратора, установив флаг Конфигуратор. Как видите, у системы нет даже имени. Сразу после входа в конфигуратор настройщик устанавливает ряд параметров, в том числе название системы.

План действий настройщика таков:

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

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

К этому добавлю, что для желающих а готов рассказать о штатной платформе. Итак, в памяти создается структура TTableInfo, содержащая атрибуты, вводимые через специальный диалог. Затем создается набор структур для полей таблицы. Для выполнения этой работы нужно разработать по крайней мере два диалога, - один для заполнения структуры TTableInfo, а другой для заполнения структуры TFieldInfo и ее добавления в структуру TTableInfo. Упрощенные реализации этих диалогов имеют вид, приведенный в листингах L1 и L2.

Листинг L1.
, приведенного в листинге L1.

Рассмотрим некоторые детали этого диалога, относящиеся к общей идеологии платформы, о которых пока не было ничего сказано. Это касается свойства ppTInfoCategory, обеспечивающего доступ к полю FpTInfoCategory : pTInfoCategory, содержащему ссылку на структуру

// Структура категории информации TInfoCategory = record sInfoID : TFbMedID; sTFbDbType : TFbDbType; sEnumName, sInfoName : TFbMedName; sInfoDescr : TFbMedDesc; sCount : Integer; sPrefix : String[5]; sMainPrefix : String[3]; sSubPrefix : String[2]; sStatusID : Byte; end;

Эта структура введена в связи с тем, что вся пользовательская информация в рассматриваемой платформе разбита на ряд категорий, чтобы легче было оперировать множеством таблиц. В частности, в медицинской тематике используются такие категории информации как Справочники, Клиенты, Персонал и др. Информация о том, что конкретная таблица относится к той или иной категории, содержится в специальном префиксе имени таблицы (поле sPrefix структуры TInfoCategory). Кроме того используется префикс для всех таблиц платформы, который позволяет отличить таблицы на сервере, с которыми оперирует платформа, от других типов таблиц, в частности, системных таблиц. Рассмотрим конкретный пример таблицы с именем Fb_c_pclients. Префикс ‘Fb_’ указывает на то, что данная таблица относится к пользовательской базе данных платформы. Далее идет префикс ‘c_’, который указывает на то, что данная таблица относится к категории Клиенты. Как видим, префиксы отделяются друг от друга и от имени таблицы знаками подчеркивания. В приведенной структуре для нашего примера могут быть, например, такие значения:

sInfoID = ‘001111’, sTFbDbType = icClient, sEnumName = ‘icClient’, sInfoName = ‘InfoName_001111’, sInfoDescr = ‘Клиенты’, sPrefix = ‘Fb_c’, sMainPrefix = ‘Fb_’, sSubPrefix = ‘c_’.

Поля sCount и sStatusID имеют специальное назначение, выходящее за пределы обсуждения, и пока практически в платформе не используются. Для работы с категориями введены следующие конструкции:

специальный перечислимый тип

// Тип категорий информации TFbDbType = ( icOther, // Прочие icSpr, // Справочники icClient, // Клиенты icStaff, // Персонал icStatist, // Статистика icJournal, // Журналы icAll, // Все категории icNoCateg); // Без категории,

вспомогательные типы для хранения описаний категорий информации

// Тип паспорта категории информации TFbDbTypeItem = Array [1..2] of String; // Тип массива паспортов категорий информации TFbDbTypeArray = Array [TFbDbType] of TfbDbTypeItem,

и константа-массив префиксов для выбранных категорий информации

apDbTypeArray : TFbDbTypeArray = ( { Категория информации и префиксы имен таблиц } { , } ('Прочие', 'Fb_o_'), ('Справочники', 'Fb_s_'), ('Клиенты', 'Fb_c_'), ('Персонал', 'Fb_m_'), ('Статистика', 'Fb_r_'), ('Журналы', 'Fb_j_'), ('Виртуальная БД', 'Fb_v_'), ('Все категории', 'Fb___'), ('Без категории', 'Fb_' ) )

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

Вернемся к нашему диалогу формирования структуры таблицы. Суть его работы сводится к формированию специальной буферной структуры таблицы FN_pTTableInfo для текущего экземпляра интерфейса к базам данных (по клику на кнопке ОК) в методе FDbInterface.Init_NpTTableInfo и переходу в диалог работы со списком полей TbDefFr. Если при выходе из диалога TbDefFr пользователь откажется от создания таблицы, то буферная структура будет удалена из памяти. Если же процесс создания таблицы будет завершен успешно, то судьба буферной структуры поля окончательно будет решена после выхода из диалога TbDefFr. Сама буферная структура FN_pTTableInfo является принадлежностью интерфейса к базам данных FDbInterface.

Ниже приводится программный код для диалога создания структуры поля.

Листинг L2.
, приведенного в листинге L2.

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