Очень часто требуется задать ограничения на поля, но очень не хочется описывать в интерфейсе сложные проверки. Не хочется ... и не надо. Можно воспользоваться механизмом alterator который носит недвусмысленное название constraints.
Первым делом заставим бакенд отвечать на новый вопрос – constraints. Ответ он должен отдавать в следующей форме:
Где <ограничения> есть следующий список:
Доступны следующие виды ограничений:
В ближайшем будущем будет добавлен механизм, позволяющий расширять список доступных ограничений
Пример:
В данном случае мы сообщаем, что параметры name, passwd1 и passwd2 являются обязательными, кроме того параметр name1 должен соответствовать шаблону "^a.*b$", а параметр passwd1 совпадать с параметром passwd2. Для параметра gecos также приведено сообщение об ошибке, которое должно выводиться в случае не соотвествия значения поля шаблону "^[a-z].*$" .
Для каждого параметра ограничения обрабатываются последовательно слева на право и останавливается на первом обнаруженном несоответствии. Таким образом изменяя порядок требований вы можете управлять сообщениями об ошибке.
Как теперь воспользоваться этими параметрами? Параллельно серии функций woo-* существует серия woo-*/constraints. Их главное отличие в том что проводится предварительная проверка передаваемых параметров на соответствие заданным правилам. В случае успеха запрос выполняется – иначе выкидывается исключение woo-error с подробным перечислением обнаруженных проблем.
Пример:
А что делать если для разных действий требуются разные ограничения? При использовании функции woo-*/constraints при выполнении запроса constraints, бакенду передаётся полный список параметров и кроме того в параметре orig_action указано для какого действия запрашиваются ограничения. Например, в случае woo-new/constraints параметр orig_action равен “new”. Благодаря этому, можно, например, сделать разные ограничения для действий woo-new и woo-write.