Добрый день!
Появился интересный вопрос к аналитика web-приложений:
Каким образом лучше организовать описание валидации полей Web-форм?

Мое предложение:
1. Отдельным разделом документа выносится общая валидация для всех полей (описание механики подсказок, ошибочных сообщений и т.п.)
2. Отдельным разделом добавляется соответствие поля и его параметров валидации (конкретные сообщения и т.п.)

Может у кого есть вариант получше?

А почему сразу не добавлять это в описание полей?
И я бы не стал смешивать это с сообщениями об ошибках.

А почему сразу не добавлять это в описание полей?
И я бы не стал смешивать это с сообщениями об ошибках.

По первому пункту: Придется мониторить весь документ при изменении, а не один раздел.
По второму пункту: Это сообщения о валидационных ошибках, что не совсем является ошибкой.

По первому пункту: Придется мониторить весь документ при изменении, а не один раздел.

Это гораздо легче, чем заставить программистов искать "свои" поля в какой-то общей свалке. Особенно когда их много.

Кроме того, валидация может быть условной, тогда отрывать правила валидации от логики формы вообще неразумно.

Описывать поля формы надо в разделе с описанием этой формы. Вынесете куда-то еще - сильно увеличите риск того, что прописанное не будет реализовано (или будет реализовано не так).

Обычно заводят или отдельный столбец в описании полей, или отдельную таблицу, если писать много.

P.S. Кстати, про валидацию вообще и "условную" в частности. В отечественной практике эта активность издавна носила куда более осмысленное и говорящее само за себя название "форматно-логический контроль" (он же ФЛК). Ух, сколько аналитиков и проектов набили шишки из-за банального незнания этого названия...

Добрый день!
Появился интересный вопрос к аналитика web-приложений:
Каким образом лучше организовать описание валидации полей Web-форм?

Мое предложение:
1. Отдельным разделом документа выносится общая валидация для всех полей (описание механики подсказок, ошибочных сообщений и т.п.)
2. Отдельным разделом добавляется соответствие поля и его параметров валидации (конкретные сообщения и т.п.)

Может у кого есть вариант получше?

А что здесь такого вебового? Это относится к любым графическим интерфейсам — хоть десктопным, хоть мобильным.

Других вариантов мне неизвестно.

В части описания структур данных я использую дублирование — описываю структуру и в тексте функционального требования и в словаре данных.

В идеальной СУТ конечно должна быть возможность вставить правила валидации со ссылкой на общий словарь валидаций так, чтобы при правке в одном месте правилось и в другом.

Какой именно подход вам больше подойдёт — только по месту, только отдельно или и то и другое — зависит от специфики проекта, какие операции кто чаще будет делать с этим документом.

Спасибо огромное за ваши ответы!
Буду вносить валидацию в таблицы с описаниями полей.