Сначала опишите допустимые значения
Для условной формы нужны имя, адрес электронной почты и количество участников. У каждого поля своя задача. Имя не должно состоять только из пробелов; почтовый адрес должен соответствовать ожидаемому формату; количество должно быть целым числом от 1 до 4. Это правила нашего примера, а не универсальный стандарт любых форм. Полезно записать их до оформления страницы. Тогда дизайнер, разработчик интерфейса и серверной части обсуждают одну и ту же модель, а не независимо придумывают разные ограничения.
Браузер помогает исправить ошибку
Проверка на стороне клиента может сразу показать, что обязательное поле пустое или число вышло за допустимый диапазон. Хорошее сообщение связано с конкретным действием: указать целое количество от одного до четырёх. Общая фраза о неверных данных заставляет человека угадывать проблему. При этом не стоит стирать уже заполненные поля после каждой ошибки. Пользователь должен видеть, что именно осталось исправить. Проверка удобства включает несколько сценариев: ввод с клавиатуры, исправление одного поля и повторную попытку после понятного сообщения.
Сервер проверяет собственные правила
Полученный запрос рассматривают как недоверенные данные, даже если он обычно отправляется красивой знакомой формой. Сервер должен проверить обязательность, типы, диапазоны и применимые ограничения перед выполнением действия. В нашем примере значение 7 не становится допустимым потому, что в браузере кнопка отправки была доступна. Проверка ввода также не заменяет другие меры защиты и контроля доступа. Она отвечает на вопрос о допустимости данных, но не доказывает автоматически, что отправитель вправе выполнить любую операцию или что дальнейшая обработка реализована безопасно.
Допустимый формат ещё не означает выполненную заявку
Даже корректные значения могут столкнуться с отдельным правилом процесса: например, свободных мест уже нет. Это отличается от ошибки формата и требует другого сообщения. Также нужно различать отправку запроса и подтверждённое завершение действия. Если соединение оборвалось, интерфейс не должен уверенно объявлять успех без основания. Для учебного проектирования полезно заранее описать состояния: можно заполнить, есть ошибки, идёт отправка, получен отказ по условиям, получено подтверждение. Такой перечень помогает не забыть ситуации, которые не видны на статичном макете формы.
Попробуйте на практике
Составьте набор проверок для вымышленной формы на бумаге. Программирование, реальные адреса и отправка данных не требуются.
- Запишите правила трёх полей: непустое после удаления внешних пробелов имя, ожидаемый формат почты и целое количество от 1 до 4.
- Для количества перечислите случаи 0, 1, 4, 5 и 2,5. Отметьте допустимые и недопустимые значения.
- Придумайте отдельное сообщение для пустого имени и для недопустимого количества, указывая способ исправления.
- Добавьте сценарий прямого запроса со значением 7, минуя интерфейс. Укажите, какая сторона обязана его отклонить.
- Опишите ответы для двух разных ситуаций: мест нет и заявка подтверждена. Не смешивайте их с ошибкой заполнения.
Как проверить результат. Допустимы количества 1 и 4; остальные перечисленные значения не проходят заданные правила. Серверная проверка обязательна и для прямого запроса, а корректный ввод отделён от успешного выполнения заявки.
Частые вопросы
Если поле имеет встроенную проверку браузера, серверную можно убрать?
Нет. Клиентская проверка помогает пользователю, но сервер не может полагаться на то, что она обязательно была выполнена.
Проверка данных полностью защищает приложение?
Нет. Она является частью защиты и корректной обработки. Контроль доступа, безопасная работа с хранилищем и другие меры решают отдельные задачи.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.