Очень часто требуется задать ограничения на поля, но очень не хочется описывать в интерфейсе сложные проверки. Не хочется ... и не надо. Можно воспользоваться механизмом 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.
Заполнение пользователем формы как правило происходит без какого либо фонового взаимодействия с сервером (возможны небольшие исключения), проверка правильности заполнения формы происходит уже после того как пользователь нажал кнопку «Принять результаты».
C другой стороны, если оповесить клиентскую сторону об имеющихся ограничениях заранее, то «браузер» сможет «подсказывать» пользователю о том как следует правильно заполнять те или иные поля. Например можно интерактивно «гасить» исключённые поля или включать из обратно, как-то отмечать поля, требуемые по-умолчанию.
Образно говоря – посылка формы – это когда студент говорит ответ преподавателю на экзамене. А визуализация – это когда преподаватель подмигивает, намекая на правильный вопрос.
Подобная визуализация с одной стороны позволяет сэкономить время, с другой трафик (хотя вообще говоря всё равно где будет находиться логика проверки ограничений). Кроме того эта служба не навязчива (нет, так нет) и визуальное представление зависит исключительно от браузера (как смог так и нарисовал).
При использовании lookout, для того чтобы сообщить браузеру об имеющихся ограничениях, задайте виджетам имена, соответствующие именам полей (параметр widget-name) и добавьте иструкцию следующего вида:
Формат команды update-constraints такой же как и у woo-try: действие, объект, параметры.
В случае использования fbi, ничего дополнительно делать не надо.
Как обычно визуализируются constraints: