Формообразование. Уверенная поступь
Я занимаюсь профессиональной разработкой Систем Управления Базами Данных (СУБД) уже несколько лет, поэтому большой интерес вызвала у меня серия статей А. Запольскиса об основах построения форм, в частности в среде СУБД Аccess. Нисколько не умаляя профессиональных навыков автора и не подвергая сомнению подходов, предлагаемых Александром, хочу дополнить тему своими взглядами на проектирование интерфейса СУБД.
Прежде всего замечу, что мой любимый инструмент - это СУБД Visual Fox Pro 5.0. Я специально делаю эту оговорку, так как возможности Access и Visual FoxPro существенно отличаются. Понятно, что многие мои примеры основаны на возможностях, предоставляемых FoxPro.
В своей статье Александр неоднократно подчеркивал трудоемкость программирования контроля ввода и "отлова" недопустимых действий пользователя. К счастью, сейчас все больше распространение получает более совершенный метод проектирования СУБД, связанный прежде всего с понятиями "хранимые правила и процедуры". База данных в этом случае представляется не просто в виде набора файлов с пусть и четко структурированными, но все же мало защищенными "от дурака" данными, а в виде объекта-контейнера, в состав которого входит уже минимум два компонента - непосредственно данные и правила их обработки (я написал "минимум", поскольку в реальности в состав БД в Visual FoxPro можно включить еще несколько компонентов: локальные представления, удаленные представления, триггеры, хранимые процедуры и другие полезные вещи).
Если мы упрощенно рассмотрим это на практике, то картина будет следующей. Воспользуемся теми же данными, с которыми работал Александр. У нас есть таблица "Литература", в которой есть два поля: "Название" и "Автор".
Представим, что в эту таблицу мы вводим данные с помощью формы. Естественно, форма спроектирована должным образом - записи с пустым значением полей "Название" и "Автор" программа будет отвергать и попросит в этом случае заполнить необходимые поля. Для достижения этого эффекта необходимо запрограммировать контроль на ввод пустых значений. В данном случае это сделать легко, вставив несколько строк кода для каждого поля на форме (используя функцию типа Empty()), поскольку мы имеем дело только с двумя полями. А если мы работаем в обход формы? Давайте представим, что кто-то (случайно) открыл таблицу с вашими драгоценными данными и очистил значение "Автор" одной из записей, скажем, при помощи команды табличного просмотра-редактирования таблиц BROWSE (в FoxPro). Реакции на надругательство не будет никакой. И это самый безобидный случай. А если очищенное поле являлось полем-связкой с другой таблицей? Это уже близко к катастрофе.
Встроенные возможности аппарата БД Visual Fox Pro позволяют вам пресечь все попытки в изменении критических данных благодаря механизму встроенных правил. Обратимся к таблице "Литература": при создании ее традиционным методом мы лишь описываем структуру таблицы (см. табл.1).
При использовании возможностей хранимых правил для каждого поля мы можем добавить еще несколько атрибутов - правило проверки и сообщение об ошибке.
В нашем случае это будет выглядеть так (см. табл.2).
Введенные правила будут записаны в самой структуре БД один раз, и их более незачем дублировать в формах. Что мы получим в результате? Каким бы способом доступа к данным ни воспользовался пользователь (форма, SQL команда, редактирование "в лоб"), система активизирует правила для каждого поля, предусмотренные на этапе проектирования структуры таблицы, и ни за что не примет некорректных данных, выдав при этом предусмотренное сообщение об ошибке. Кроме очевидного достижения корректности ввода, мы сразу добиваемся и роста производительности разработки: как только мы связываем поле данных таблицы, для которого установлены правила проверки с элементом управления на форме, эти правила будут сразу же срабатывать при манипуляции над данными этого элемента управления. Без утомительного прописывания (порой одного и того же) программного кода. То есть - в нашем случае для построения формы ввода в таблицу "Литература" достаточно перетащить на чистую форму соответствующие поля из таблицы, добавить заголовок и кнопку сохранения. Работа над формой закончена.
Такой подход позволяет создавать сложные, с большим количеством элементов управления формы, не прибегая к избыточному кодированию. В качестве иллюстрации этих возможностей может служить моя собственная форма (Рис. 1), входящая в состав программы-каталогизатора домашней фонотеки.
Взгляните - здесь и поля ввода, и список, и чекбоксы и много еще чего, общим количеством элементов ввода - 15. Тем не менее, несмотря на большое количество элементов управления, почти за каждым из них стоит своя соответствующая проверка. Причем без единой строки кода в самой форме! Работа по программированию была сделана на этапе проектирования БД. Удобно? Я думаю, ответ очевиден.
Основываясь на проиллюстрированном примере, хочу обратить внимание программистов СУБД на следующий тезис: возможности современных СУБД позволяют разработчику отвлечься от рутинных операций по программированию пользовательского интерфейса и сфокусировать свои усилия на разработке структуры базы данных. Этот тезис не нов, и для меня он давно очевиден, но не всегда бесспорен. Причем, только в первой его части "отвлечься от рутинного программирования пользовательского интерфейса".
Визуальная система разработки форм дала нам воистину потрясающие возможности - мы можем сделать формы любого вида - от "навороченных" футуристически-техногенных до простых и примитивных в стиле "детский наив". Многие стараются эту возможность использовать "на всю катушку". У кого-то получается лучше, у кого-то - хуже, кому-то же просто изменяет чувство меры, а у кого-то напрочь отсутствует фантазия. Однако, сейчас заметна другая тенденция - использовать только стандартные компоненты интерфейса (в стиле Windows, разумеется), графикой пользоваться только там, где она необходима (скажем, фото сотрудников), и постараться обходиться без всяких "рюшечек-цветочков". В этой тенденции есть два больших плюса:
1. Поскольку все элементы стандартны, то пользователю не нужно дополнительное время на освоение взаимодействия с системой. Имея накопленный опыт работы с другими приложениями, пользователь пытается применить этот опыт и при "общении" с новой системой. Хорошо, если новая система это позволяет и достаточно дружественна. В качестве игнорирования этого факта и мягкого издевательства над пользователем могу привести, на мой взгляд, довольно яркий пример, боюсь, правда, что вызову шквал недовольных окриков. Кто пользуется программой Adobe Photoshop, наверняка прикрутил себе и фильтры от Kai. При несомненной ценности продукта и оригинального эстетического решения интерфейса требуется чудовищно долгое время на его освоение. Попросту говоря, долго тыкаешься в эти миленькие кнопки-шарики, пока выяснишь, что же они и как делают, - в конце концов в сердцах жмешь на F1 и... До интуитивно-понятного такому интерфейсу еще далеко.
Быстрое освоение новой программы может иметь решающее значение для автоматизации промышленных предприятий, больших офисов и других организаций, имеющих большое количество компьютеризированных рабочих мест. Ценность украшений здесь будет сомнительна. Требуется лишь грамотно подобранная цветовая гамма и функциональная насыщенность приложения.
2. Второй плюс относится уже скорее к разработчикам, чем к пользователям. Поскольку все основные элементы управления уже разработаны (по крайней мере их внешний вид и зачаточная функциональность), разработчику не нужно тратить время на мучительный поиск своей концепции интерфейса, ему не надо "отрисовывать" кнопки, списки и прочее - все уже сделано до него и за него, осталось только скорректировать поведение этих объектов (среди западных разработчиков этот процесс называется более точно - customizing). Таким образом получается существенная экономия времени при разработке приложения.
Все выглядит замечательно, не правда ли? Но...
Представьте, что вдруг все люди будут ходить в одинаковой одежде. Пусть от самого крутого модельера и скроенной по самой последней моде. Города превратятся в угрюмые бетонные джунгли с одинаковыми жителями, упакованными в стандартную, трижды сертифицированную и признанную лучшей одежду. Жуть? Если спроецировать это на программирование... ну, представьте себе Quake, сработанный в стиле Microsoft Office...
Все-таки как ни крути, а человеческая натура такова, что требует проявления индивидуальности. Тем более, что творческие и гибкие люди (не только на Западе) уже доказали жизнеспособность другого тезиса: "При одинаковой функциональной насыщенности нескольких программ, имеющихся на рынке, наиболее конкурентноспособной будет программа с наиболее эффектным интерфейсом". Особенно это касается развлекательных вещей типа мультимедийных энциклопедий (у которых, кстати, ядро построено зачастую на архитектуре СУБД) и домашних приложений. В самом деле, ну кому захочется просматривать каталог видеозаписей при помощи самой стандартной и привычно выглядящей командной строки?
Исходя из приведенных выше соображений я конструирую экранные формы в зависимости от их назначения. При разработке приложений для промышленного использования я избегаю ярких решений и замысловатых интерфейсов, а пользуюсь стандартными элементами. Быстро и производительно. Если работа идет над программой для "домашнего" применения - я большее значение придаю внешнему виду форм (не в ущерб функциональности, разумеется, см. рис.2).
Конечно, много затрат приходится на рисование стандартных, уже существующих компонентов, однако старания не напрасны - формы приобретают характерный, "фирменный" вид.
Приведенные формы и принципы их построения не претендуют на абсолютную "правильность" и являются лишь одним из многочисленных вариантов решения специфических задач. Однако умелое сочетание всех изложенных подходов (да и не только этих), хорошее знание возможностей инструмента и художественный вкус позволяет достичь весьма высоких результатов и благодарности пользователей.
Таблица 1. Структура таблицы "Литература"
Таблица 2. Структура таблицы "Литература" с использованием правил проверки на уровне полей
Виктор Гмыря
Прежде всего замечу, что мой любимый инструмент - это СУБД Visual Fox Pro 5.0. Я специально делаю эту оговорку, так как возможности Access и Visual FoxPro существенно отличаются. Понятно, что многие мои примеры основаны на возможностях, предоставляемых FoxPro.
В своей статье Александр неоднократно подчеркивал трудоемкость программирования контроля ввода и "отлова" недопустимых действий пользователя. К счастью, сейчас все больше распространение получает более совершенный метод проектирования СУБД, связанный прежде всего с понятиями "хранимые правила и процедуры". База данных в этом случае представляется не просто в виде набора файлов с пусть и четко структурированными, но все же мало защищенными "от дурака" данными, а в виде объекта-контейнера, в состав которого входит уже минимум два компонента - непосредственно данные и правила их обработки (я написал "минимум", поскольку в реальности в состав БД в Visual FoxPro можно включить еще несколько компонентов: локальные представления, удаленные представления, триггеры, хранимые процедуры и другие полезные вещи).
Если мы упрощенно рассмотрим это на практике, то картина будет следующей. Воспользуемся теми же данными, с которыми работал Александр. У нас есть таблица "Литература", в которой есть два поля: "Название" и "Автор".
Представим, что в эту таблицу мы вводим данные с помощью формы. Естественно, форма спроектирована должным образом - записи с пустым значением полей "Название" и "Автор" программа будет отвергать и попросит в этом случае заполнить необходимые поля. Для достижения этого эффекта необходимо запрограммировать контроль на ввод пустых значений. В данном случае это сделать легко, вставив несколько строк кода для каждого поля на форме (используя функцию типа Empty()), поскольку мы имеем дело только с двумя полями. А если мы работаем в обход формы? Давайте представим, что кто-то (случайно) открыл таблицу с вашими драгоценными данными и очистил значение "Автор" одной из записей, скажем, при помощи команды табличного просмотра-редактирования таблиц BROWSE (в FoxPro). Реакции на надругательство не будет никакой. И это самый безобидный случай. А если очищенное поле являлось полем-связкой с другой таблицей? Это уже близко к катастрофе.
Встроенные возможности аппарата БД Visual Fox Pro позволяют вам пресечь все попытки в изменении критических данных благодаря механизму встроенных правил. Обратимся к таблице "Литература": при создании ее традиционным методом мы лишь описываем структуру таблицы (см. табл.1).
При использовании возможностей хранимых правил для каждого поля мы можем добавить еще несколько атрибутов - правило проверки и сообщение об ошибке.
В нашем случае это будет выглядеть так (см. табл.2).
Введенные правила будут записаны в самой структуре БД один раз, и их более незачем дублировать в формах. Что мы получим в результате? Каким бы способом доступа к данным ни воспользовался пользователь (форма, SQL команда, редактирование "в лоб"), система активизирует правила для каждого поля, предусмотренные на этапе проектирования структуры таблицы, и ни за что не примет некорректных данных, выдав при этом предусмотренное сообщение об ошибке. Кроме очевидного достижения корректности ввода, мы сразу добиваемся и роста производительности разработки: как только мы связываем поле данных таблицы, для которого установлены правила проверки с элементом управления на форме, эти правила будут сразу же срабатывать при манипуляции над данными этого элемента управления. Без утомительного прописывания (порой одного и того же) программного кода. То есть - в нашем случае для построения формы ввода в таблицу "Литература" достаточно перетащить на чистую форму соответствующие поля из таблицы, добавить заголовок и кнопку сохранения. Работа над формой закончена.
Такой подход позволяет создавать сложные, с большим количеством элементов управления формы, не прибегая к избыточному кодированию. В качестве иллюстрации этих возможностей может служить моя собственная форма (Рис. 1), входящая в состав программы-каталогизатора домашней фонотеки.
Взгляните - здесь и поля ввода, и список, и чекбоксы и много еще чего, общим количеством элементов ввода - 15. Тем не менее, несмотря на большое количество элементов управления, почти за каждым из них стоит своя соответствующая проверка. Причем без единой строки кода в самой форме! Работа по программированию была сделана на этапе проектирования БД. Удобно? Я думаю, ответ очевиден.
Основываясь на проиллюстрированном примере, хочу обратить внимание программистов СУБД на следующий тезис: возможности современных СУБД позволяют разработчику отвлечься от рутинных операций по программированию пользовательского интерфейса и сфокусировать свои усилия на разработке структуры базы данных. Этот тезис не нов, и для меня он давно очевиден, но не всегда бесспорен. Причем, только в первой его части "отвлечься от рутинного программирования пользовательского интерфейса".
Визуальная система разработки форм дала нам воистину потрясающие возможности - мы можем сделать формы любого вида - от "навороченных" футуристически-техногенных до простых и примитивных в стиле "детский наив". Многие стараются эту возможность использовать "на всю катушку". У кого-то получается лучше, у кого-то - хуже, кому-то же просто изменяет чувство меры, а у кого-то напрочь отсутствует фантазия. Однако, сейчас заметна другая тенденция - использовать только стандартные компоненты интерфейса (в стиле Windows, разумеется), графикой пользоваться только там, где она необходима (скажем, фото сотрудников), и постараться обходиться без всяких "рюшечек-цветочков". В этой тенденции есть два больших плюса:
1. Поскольку все элементы стандартны, то пользователю не нужно дополнительное время на освоение взаимодействия с системой. Имея накопленный опыт работы с другими приложениями, пользователь пытается применить этот опыт и при "общении" с новой системой. Хорошо, если новая система это позволяет и достаточно дружественна. В качестве игнорирования этого факта и мягкого издевательства над пользователем могу привести, на мой взгляд, довольно яркий пример, боюсь, правда, что вызову шквал недовольных окриков. Кто пользуется программой Adobe Photoshop, наверняка прикрутил себе и фильтры от Kai. При несомненной ценности продукта и оригинального эстетического решения интерфейса требуется чудовищно долгое время на его освоение. Попросту говоря, долго тыкаешься в эти миленькие кнопки-шарики, пока выяснишь, что же они и как делают, - в конце концов в сердцах жмешь на F1 и... До интуитивно-понятного такому интерфейсу еще далеко.
Быстрое освоение новой программы может иметь решающее значение для автоматизации промышленных предприятий, больших офисов и других организаций, имеющих большое количество компьютеризированных рабочих мест. Ценность украшений здесь будет сомнительна. Требуется лишь грамотно подобранная цветовая гамма и функциональная насыщенность приложения.
2. Второй плюс относится уже скорее к разработчикам, чем к пользователям. Поскольку все основные элементы управления уже разработаны (по крайней мере их внешний вид и зачаточная функциональность), разработчику не нужно тратить время на мучительный поиск своей концепции интерфейса, ему не надо "отрисовывать" кнопки, списки и прочее - все уже сделано до него и за него, осталось только скорректировать поведение этих объектов (среди западных разработчиков этот процесс называется более точно - customizing). Таким образом получается существенная экономия времени при разработке приложения.
Все выглядит замечательно, не правда ли? Но...
Представьте, что вдруг все люди будут ходить в одинаковой одежде. Пусть от самого крутого модельера и скроенной по самой последней моде. Города превратятся в угрюмые бетонные джунгли с одинаковыми жителями, упакованными в стандартную, трижды сертифицированную и признанную лучшей одежду. Жуть? Если спроецировать это на программирование... ну, представьте себе Quake, сработанный в стиле Microsoft Office...
Все-таки как ни крути, а человеческая натура такова, что требует проявления индивидуальности. Тем более, что творческие и гибкие люди (не только на Западе) уже доказали жизнеспособность другого тезиса: "При одинаковой функциональной насыщенности нескольких программ, имеющихся на рынке, наиболее конкурентноспособной будет программа с наиболее эффектным интерфейсом". Особенно это касается развлекательных вещей типа мультимедийных энциклопедий (у которых, кстати, ядро построено зачастую на архитектуре СУБД) и домашних приложений. В самом деле, ну кому захочется просматривать каталог видеозаписей при помощи самой стандартной и привычно выглядящей командной строки?
Исходя из приведенных выше соображений я конструирую экранные формы в зависимости от их назначения. При разработке приложений для промышленного использования я избегаю ярких решений и замысловатых интерфейсов, а пользуюсь стандартными элементами. Быстро и производительно. Если работа идет над программой для "домашнего" применения - я большее значение придаю внешнему виду форм (не в ущерб функциональности, разумеется, см. рис.2).
Конечно, много затрат приходится на рисование стандартных, уже существующих компонентов, однако старания не напрасны - формы приобретают характерный, "фирменный" вид.
Приведенные формы и принципы их построения не претендуют на абсолютную "правильность" и являются лишь одним из многочисленных вариантов решения специфических задач. Однако умелое сочетание всех изложенных подходов (да и не только этих), хорошее знание возможностей инструмента и художественный вкус позволяет достичь весьма высоких результатов и благодарности пользователей.
Таблица 1. Структура таблицы "Литература"
| Название поля | Тип данных | Размер |
| Название книги | Символьный | 40 |
| Автор книги | Символьный | 30 |
| Название поля | Тип данных | Размер | Правило проверки | Сообщение об ошибке |
| Название книги | Символьный | 40 | .NOT.Empty(Название книги) | "Поле 'Название книги' должно быть заполнено" |
| Автор книги | Символьный | 30 | .NOT.Empty(Автор книги) | "Поле 'Автор книги' должно быть заполнено" |
Компьютерная газета. Статья была опубликована в номере 24 за 1999 год в рубрике soft :: субд
