Валидация формы
Валидация формы происходит в InstanceDraftRegister.validateDraft().
Есть следующие стратегии валидации формы:
Полная
Измененные поля
Сохранение сигнатуры
Первая валидация
Они отличаются количеством валидируемых полей.
Например, при "первой валидации" поля НЕ валидируются.
При "полной" или "сохранении сигнатуры" валидируются все динамические поля БО.
При "измененных полях" валидируются поля, которые были изменены внутри этого черновика.
Данные стратегии вызываются в определенных жизненных циклах формы.
Так, при создании черновика формы вызывается первичная валидация (важно учесть, что вызов зависит от клиента, то есть если запрос не будет сделан, сам апи не будет вызывать, и данный жизненный цикл может просто "выпасть")
При изменении поля используется стратегия "Измененные поля", и это контролируется апи.
При сохранении формы используется стратегия "Полная", и это контролируется апи.
При подписании формы используется стратегия "Сохранение сигнатуры", и это контролируется отчасти апи. Подписание инстанции не работает в черновике, поэтому перед подписанием надо создать инстанцию (если она существует только в черновике), либо же зафиксировать все изменения. Если клиент вызовет метод InstanceDraftRegister.createInstanceBySignature(), апи использует данную стратегию.
Валидация полей
Поля черновика валидируется с помощью BoiFieldValidator.
Процесс валидации разбит на несколько "раундов".
Разделение валидации на несколько раундов (этапов) обосновывается гибкостью, понятностью и масштабируемостью.
Гибкость - раунды можно переопределить для конкретных видов полей
Понятность - раунды логически разделяют процесс валидации, с меньшим объемом кода легче работать
Масштабируемость - можно легко добавлять новые раунды, при этом необъязательно для всех типов полей
явно указывать логику, достаточно указать единую логику в родительском классе
Раунды
Существуют следующие виды раундов:
| Тип | Можно переопределить | Объязательность | Очередность |
|---|---|---|---|
| Pre-validation | нельзя | объязателен | 1 |
| Parse validation | нельзя | объязателен | 2 |
| Empty validation | можно | объязателен | 3 |
| Value validation | можно | не объязателен | 4 |
| Logic validation | можно | не объязателен | 5 |
| Post-validation | нельзя | объязателен | 6 |
Pre-validation
На данном этапе значение может быть пустым
Проверяются общие, легкие проверки (например, проверка на объязательность)
Parse validation
На данном этапе значение не может быть пустым
Значение проверяется на корректность storedValue
Пример: в INPUT_NUMBER нельзя хранить символы
Empty validation
На данном этапе значение не может быть пустым
Значение проверяется на пустоту, но не на null и blank
Например, "[]" - не null и не blank, однако это пустое значение для полей типа BO и CO
Value validation
На данном этапе значение не может быть пустым
Проверяется дополнительная логика storedValue
Например, "Parse validation" не проверяет корректность паттерна телефонного номера
Logic validation
На данном этапе значение не может быть пустым
Проверяется бизнес-логика
Post-validation
На данном этапе значение не может быть пустым
Проверяются общие, тяжелые проверки
Например, проверка на уникальность
Общая логика прохождения раундов
Раунды проходят один за другим, это значит, что неуспешное прохождение одного раунда прерывает весь процесс валидации.
По этой же причине рекомендуется проводить раунды по мере возрастания сложности проверки.
Рекомендации
Очень желательно, чтобы новые проверки попадали в нужные раунды.
Таким образом проверка будет находиться в логически правильном месте и облегчить жизнь другим разработчикам.
Пример: допустим, что все текстовые поля теперь должны начинаться на "A" (все, без исключения). На первый взгляд можно подумать, что проверка относится к Logic validation, так как проверяется бизнес логика. Однако в данном случае проверка относится к Value validation, так как проверяется значение на какой то паттерн.
Точно так же, новый раунд (помимо этих 6) рекомендуется добавлять, ТОЛЬКО если все 6 раундов не удовлетворяют условия.
Помните, что проверку КАЖДОГО поля можно кастомизировать, а именно переопределить раунды, которые разрешаются (см выше таблицу).