Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/Alterator/constrains ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия AltLinux/Sisyphus/Alterator/constrains за 2006-12-15 12:18:13..

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


Очень часто требуется задать ограничения на поля, но очень не хочется описывать в интерфейсе сложные проверки. Не хочется ... и не надо. Можно воспользоваться механизмом 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:



 
Файлов нет. [Показать файлы/форму]
Много комментариев (2). [Показать комментарии/форму]