Задание ограничений на поля

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

Создание ограничений

Первым делом заставим бакенд отвечать на новый вопрос – constraints. Ответ он должен отдавать в следующей форме:
(параметр1 <ограничения> параметр2 <ограничения> ...)
Где <ограничения> есть следующий список:
(ограничение1 параметры-ограничения-1 ограничение2 параметр-ограничения-2 ...)

Доступны следующие виды ограничений:

• match – параметр должен соответвовать указанному регулярному выражению. В качестве параметра передаётся или шаблон или список из шаблона и сообщения в случае ошибки (читать регулярные выражения с экрана могут далеко не все пользователи ;) )
• equal – параметр должен совпадать со значением другого параметра
• required – указывает на обязательность/необязательность наличия данного параметра
• ipv4-address – указывает должно ли содержимое поля соответствовать правилам написания IPv4 адреса
• hostname – указывает должно ли содержимое поля соотвествтовать правилам написания имён хостов.
• default – задаёт значение по-умолчанию, с успехом может применяться для задания значений по умолчанию для вновь создаваемых объектов, а также исправления особенности HTML-форм, когда незаполненные input не учавствуют в POST запросе.

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

Пример:
( name (required #t match "^a.*b$") passwd1 (required #t equal passwd2) passwd2 (required #t) gecos (match ("^[a-z].*$" "wrong comment")) )

В данном случае мы сообщаем, что параметры name, passwd1 и passwd2 являются обязательными, кроме того параметр name1 должен соответствовать шаблону "^a.*b$", а параметр passwd1 совпадать с параметром passwd2. Для параметра gecos также приведено сообщение об ошибке, которое должно выводиться в случае не соотвествия значения поля шаблону "^[a-z].*$" .

Для каждого параметра ограничения обрабатываются последовательно слева на право и останавливается на первом обнаруженном несоответствии. Таким образом изменяя порядок требований вы можете управлять сообщениями об ошибке.

Запуск проверок

Как теперь воспользоваться этими параметрами? Параллельно серии функций woo-* существует серия woo-*/constraints. Их главное отличие в том что проводится предварительная проверка передаваемых параметров на соответствие заданным правилам. В случае успеха запрос выполняется – иначе выкидывается исключение woo-error с подробным перечислением обнаруженных проблем.

Пример:
(button "apply" (when clicked (woo-catch/message (thunk (woo-new/constraints "/users" 'name name 'passwd1 p1 'passwd2 p2)))))

А что делать если для разных действий требуются разные ограничения? При использовании функции woo-*/constraints при выполнении запроса constraints, бакенду передаётся полный список параметров и кроме того в параметре orig_action указано для какого действия запрашиваются ограничения. Например, в случае woo-new/constraints параметр orig_action равен “new”. Благодаря этому, можно, например, сделать разные ограничения для действий woo-new и woo-write.