Задание ограничений на поля
Очень часто требуется задать ограничения на поля, но очень
не хочется описывать в интерфейсе сложные проверки.
Не хочется ... и не надо. Можно воспользоваться механизмом
alterator который носит недвусмысленное название constraints.
Создание ограничений
Первым делом заставим бакенд отвечать на новый вопрос – constraints. Ответ он должен отдавать в следующей форме:
Где
<ограничения> есть следующий список:
Доступны следующие виды ограничений:
- match – параметр должен соответвовать
указанному регулярному выражению. В качестве параметра передаётся
или шаблон или список из шаблона и сообщения
в случае ошибки (читать регулярные выражения с экрана могут
далеко не все пользователи ;) )
- equal – параметр должен совпадать со значением другого параметра
- required – указывает на обязательность/необязательность наличия данного параметра
- ipv4-address – указывает должно ли содержимое поля соответствовать правилам написания IPv4 адреса
- hostname – указывает должно ли содержимое поля соотвествтовать правилам написания имён хостов.
- exclude – позволяет указать
взаимно-исключающие друг-друга условия. Имеет два параметра:
первый – при каком значении поля следует исключать, второй – какое
поле следует исключать. Самый наглядный пример – в случае
использования dhcp, поля ipaddress и default-gw не имеют
смысла.
- default – задаёт значение по-умолчанию,
с успехом может применяться для задания значений
по умолчанию для вновь создаваемых объектов, а также
исправления особенности HTML-форм, когда незаполненные input
не учавствуют в POST запросе.
В ближайшем будущем будет добавлен механизм, позволяющий расширять список доступных ограничений
Пример:
В данном случае мы сообщаем, что параметры 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:
- exclude – визуально представляется в виде активизации/деактивизации элементов управления
- required – рядом с полем появляется символ звёздочки.