Как мы обрабатываем проверки полей формы:
Проверки поля формы предварительно определены. Логика проверки кодируется для каждого поля на стороне клиента, а иногда даже на стороне сервера, это просто достичь. Однако недостатком этого подхода является то, что эти правила проверки тесно связаны с каждым полем формы, и в нашем домене каждый клиент хотел бы иметь свои собственные установленные правила проверки, что в конечном итоге вынуждает нас создавать новую ветвь кодовой базы. Когда мы создаем новую ветку, к ней добавляются затраты на обслуживание, которых мы хотим избежать.
Как мы хотим обрабатывать проверки полей формы:
Мы хотим создать механизм, который позволил бы конечному пользователю легко настраивать свои проверки с помощью удобного пользовательского интерфейса без участия технического персонала. Привилегированный пользователь может перейти к форме, выбрать поле формы и приложить к нему проверки. И когда пользователь приходит в форму для отправки данных, мы выбираем и применяем все проверки для каждого поля формы и ограничиваем пользователя, вводящего неверные данные.
Некоторые из проверок полей формы:
1. Основные
а. Необходимо
б. Только для чтения
с. Максимальная длина
2. Выражения
а. Выражение (field1> field2)
б. Многократное выражение (date1 = today.Date)
3. Регулярное выражение
а. Регулярное выражение / ^ [a-z0-9 _-] {3,16} $ /
Задача:
1. Техника для хранения этих правил проверки.
2. Получить правила проверки из хранилища (строка) в код (динамическое выполнение).
3. Предоставлять пользователю мгновенную обратную связь относительно введенных неверных данных, а не при отправке формы.
пример каркаса