Проверка данных

Материал из Eludia
Перейти к: навигация, поиск

Контроль вводимых значений на корректность – одна из самых трудоёмких составляющих в программировании WEB-интерфейсов. Если заранее не продумать достаточно гибкий и удобный механизм, то на этапе поддержки можно столкнуться с весьма серьёзными неприятностями.

Во многих технических заданиях условия корректности либо не формулируются вообще, либо фигурируют в виде требований "обязательности поля". Давайте задумаемся: фамилия – это обязательное поле при заполнении карточки пользователя? Безусловно. А если в поле "Фамилия" введена строка "1" – это условие соблюдено? Ну вот, начинается. Не просто "обязательное", а удовлетворяющее регулярному выражению /^[А-ЯЁ]([а-яё]*|[а-яё\-]+[а-яё])$/. Можно, конечно, считать, что бестолковые значения полностью на совести оператора и вы тут ни при чём, но учтите, что когда латинская "C" не будет находиться по запросу на кириллическую "С", обязательно скажут, что ваша "программа не работает".

Ветераны разработки сайтов с подпиской на новости в этом месте подумают о JavaScript-валидации. Это, конечно, вариант, но плохой. Дело даже не в том, что использовать регулярные выражения в Perl на порядок удобнее, чем в JavaScript. Просто некоторые условия проверять на клиенте либо чудовищно неэффективно, либо вообще невозможно. Типичный пример: условие уникальности логина при многих тысячах зарегистрированных пользователей.

Таким образом, проверка данных должна осуществляться не перед отправкой запроса на сервер, а уже на сервере, но, естественно, перед модификацией данных. Сначала надо убедиться, что всё в порядке, а потом записывать или не записывать в БД предложенную порцию данных. Традиционно в Eludia проверка данных выносилась в отдельную процедуру: validate_$_REQUEST{action}_$_REQUEST{type}. Если параметры запроса удовлетворяют всем необходимым условиям, данная процедура возвращала undef, иначе – сообщение об ошибке. В настоящее время validate-процедуры по-прежнему поддерживаются, но рекомендуется осуществлять проверку данных в той же процедуре, что и собственно модификацию данных: do_$_REQUEST{action}_$_REQUEST{type}. Только сообщения об ошибках не возвращать через стек (return), а выбрасывать как ошибки (die).

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

sub do_update_users {

 $_REQUEST {_f} =~ /^[А-ЯЁ]([а-яё]*|[а-яё\-]+[а-яё])$/ or croak '#_f#: это не русская фамилия';

 ...

 do_update_DEFAULT ();

}

Объясним, как этот механизм работает с точки зрения DHTML. Прежде всего, каждая страница WEB-интерфейса на базе Eludia содержит невидимый iframe, его имя – invisible. Данный iframe является целевым (target=invisible) для всех форм и ссылок, порождающих запросы с непустыми action. Далее, HTTP-ответ, соответствующий каждому такому запросу, всегда имеет код 200 (ОК) и содержит короткий HTML-документ из единственного тега body с непустым атрибутом onLoad. Если имеет место ошибка, то обработчик onLoad высвечивает (alert) сообщение и, если требуется, переключает фокус на проблемное поле. В противном случае он открывает в родительском окне URL, на который требуется переадресовать клиент после успешного завершения операции.

Для упрощения рутинных операций проверки данных в API Eludia предусмотрен специальный раздел.

Персональные инструменты
Пространства имён

Варианты
Действия
Навигация
Разработчику
Администратору
Инструменты