Подготовка данных

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

Преобразования средствами приложения

В начале процедуры do_$_REQUEST{action}_$_REQUEST{type} (которое в унаследованном коде традиционно выносилось в отдельную подпрограмму validate_$_REQUEST{action}_$_REQUEST{type}), как правило, производится не только проверка данных на корректность, но также их правка.

Наиболее распространённый случай предварительной обработки данных: коррекция дат. Как правило, Eludia-приложения ожидают на входе даты в германском (русском) формате ДД.ММ.ГГГГ, а в записывают их в БД в формате ISO YYYY-MM-DD. Стоит отметить, что формат ISO удобно использовать для сравнения и сортировки дат, так как при этом работают алфавитные сравнения. Так вот, для проверки и одновременно преобразования дат удобно использовать процедуру vld_date, которая приводит строки вида '12.03.2006' и, скажем, '12\3-6' к формату '2006-03-12' и порождает сообщение об ошибке в том случае, если преобразование невозможно.

Кроме того, нередко в валидаторе определяются дополнительные компоненты %_REQUEST в расчёте на то, что они будут автоматически обработаны в do_update_DEFAULT.

Автоматические преобразования

Некоторые преобразования входных данных осуществляются ядром Eludia до запуска валидаторов.

Для всех параметров, введённых в формы, убираются лидирующие и хвостовые пробелы. Символы с кодами от 128 до 191 преобразуются в HTML entities (это необходимо для корректного отображения таких символов как '—' (тире), различных кавычек и т. п.)

Кроме того, все числовые данные переводятся из русского фомата (1 234,56) в перловый (1234.56). Решение о том, является ли данный параметр числовым, принимается на основании его имени (префиксы _dt и _label исключаются) и значения (регулярное выражение /^\-?[\d ]*\d([\,\.]\d+)?$/).

Как показывает практика, такой подход оправдан в подавляющем большинстве случаев, однако сам по себе он создаёт некоторые проблемы, о которых необходимо знать:

патологические опечатки
например, строка '1000, 23' из-за пробела после запятой не будет воспринята как число, хотя, возможно, тут подразумевалось 1000.23 (это приходится объяснять клиенту);
ложные срабатывания
например, строка '123 45 67' будет преобразована в число 1234567, хотя, возможно, изображает телефонный номер. В этом случае можно достать необработанное значение параметра:
$_REQUEST {_phone} = $_REQUEST_VERBATIM ('_phone');

Если вы используете Perl версии не ниже 5.8 и у вас установлен модуль Math::FixedPrecision, то числовое значение превращается в объект данного класса. Точность по умолчанию 3, её можно переопределить как параметр $conf -> {precision}. Во всех выражениях Math::FixedPrecision можно считать обычными скалярами, только вместо плавающей арифметики при этом используется фиксированная. Если вы когда-либо сталкивались с проблемой накопления погрешности в копейках, вы, вероятно, оцените такую возможность по достоинству. Однако, к сожалению, всего автоматизировать не удаётся: в проверочных выражениях помимо компонент %_REQUEST могут встречаться иные дробные значения, и за их приведение к Math::FixedPrecision отвечает уже программист.

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

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