валидация полей что это
Простая валидация формы без JS
В данной статье я бы хотел поделиться методом быстрой валидации полей с помощью разметки и стилей. Данный метод не является кроссбраузерным и рекомендуется к использованию только как дополнительная фича. По ходу статьи мы будем уменьшать наши шансы на кроссбраузерность, но повышать функциональность.
Давайте попробуем собрать стандартную форму, которая будет включать в себя: Имя, E-Mail, Телефон, Ссылку на сайт и допустим Ваш рост, чтобы поэксперементировать с числовым полем.
HTML5
Сейчас уже никого не удивить атрибутами валидации input полей, которое принес нам стандарт HTML5. Однако, обходить стороной мы его не станем — этот метод валидации является наиболее поддерживаемым в современных браузерах.
Самый простой путь валидации — это определить тип input поля и расставить атрибуты required которые отвечают за обязательность заполнения.
Применение этих двух атрибутов позволит гораздо эффективнее валидировать вводимую информацию нативными методами. Ну и конечно же поддержка этих свойств браузерами наиболее широка.
Отдельно хотелось бы сказать про тип поля tel. Ожидается что браузер будет валидировать телефонные номера, но нет, поле с типом tel используется сейчас только для автозаполнения. Дело в том, что валидация телефонных номеров очень неоднозначная задача из-за слишком большого количества различных форматов телефонных номеров в разных странах, которые просто никак не получится унифицировать и записать в одно правило.
Однако, нам на помощь приходит атрибут pattern. Этот атрибут принимает в себя значение регулярного выражения. В нашем случае рассмотрим вариант паттерна для ввода мобильного телефона в РФ: +7 (123) 456-78-91. Для этого добавим простое регулярное выражение в наше поле с телефоном, а также ограничим минимальное и максимальное количество символов:
Обычно я использую данный паттерн в связке с маской для ввода номера, но тут к сожалению без JS пока что не обойтись. Если вы не используете маску, то я бы не стал использовать паттерны на вводе телефона, поскольку это в большинстве случаев вызовет больше неудобств для пользователя.
Поддержка браузерами атрибута pattern на данный момент очень хорошая. iOS начиная с версии 10.3 полностью поддерживает данное свойство, до этого наблюдалось отсутствие подсказок о неправильном вводе данных.
Стоит также учитывать, что атрибут minlength до сих пор не поддерживается в браузерах IE, EDGE и только с версии 10.3 появился в iOS. Однако maxlength поддерживается везде и очень давно. Нам в целом хватит и этого.
Давайте также поставим ограничение для поля с ростом. Допустим мы предполагаем, что пользователь нашего сайта определенно не может быть ниже 100 см и выше 250 см. Так и напишем:
С поддержкой этих атрибутов в браузерах, все хорошо.
Перейдем к стилизации!
Для того чтобы кастомно стилизовать нашу валидацию, воспользуемся псевдоклассами :invalid и :valid. Поддержка этих псевдоклассов в браузерах позволяет использовать их максимально широко на данный момент.
Казалось бы, берем полученные знания и применяем! Но не все так просто как кажется, давайте проверим как это работает. В результате мы получим, что все наши поля изначально пустые и обязательные будут считаться не валидными, а все остальные валидными. Совсем не красиво и непонятно для пользователя, что от него хотят.
Мы можем пойти на небольшую хитрость и использовать псевдокласс :placeholder-shown. С помощью этого псевдокласса мы можем определить отображается ли сейчас значение placeholder в нашем поле ввода. Атрибут placeholder отображается только тогда, когда в наше поле ничего не введено. Соответственно, чтобы применить этот псевдокласс нам просто нужно обратить его свойство с помощью :not. В итоге получаем вот такую конструкцию:
Если прочитать дословно: окрасить красным цветом границу инпута, когда наше поле не валидно и когда в нем не отображается значение атрибута placeholder. Если ваше поле не имеет атрибута placeholder, можно просто поставить внутри пробел:
У данного метода есть только один минус: поддержка. Псевдоэлемент :placeholder-shown поддерживается во всех браузерах кроме IE и EDGE. К счастью :not не обладает таким недостатком.
Для примера я набросал все вышесказанное в CodePen и добавил еще немного возможностей:
Валидация полей формы
В данной статье я постараюсь рассказать о различных способах валидации форм и приведу конкретные примеры, которые без проблем можно будет адаптировать под свои задачи.
Валидация полей формы с помощью HTML
Поле обязательно к заполнению
Проверка ввода Email
Проверка ввода телефона
Проверка по количеству символов
Проверка ввода только букв
Проверка ввода только цифр
Как вы видите, возможности валидации полей с помощью HTML5 достаточно широкие, с помощью паттернов состоящих из регулярных выражений, можно организовать проверки практически любой сложности.
Валидация полей формы с помощью JavaScript
Наиболее сложный способ валидации на чистом JavaScript на примере простой формы обратной связи:
Обращаем внимание на то, что в свойствах формы указан параметр onsubmit=»return(validate());», что позволит выполнить функцию validate() перед отправкой формы. Теперь собственно сама функция проверки:
Проверка формата E-mail
Проверка формата телефона
Валидация полей формы с помощью плагина jQuery Validation Plugin
Данный способ валидации наиболее простой и эффективный. Единственным недостатком служит необходимость подключения библиотек jQuery и самого плагина. Если вас это не смущает, тогда смотрим примеры.
Этот плагин позволяет легко проверять формы на стороне клиента, и предлагает множество вариантов настроек. Для начала подключаем jQuery и jQuery Validation.
Затем простенькая форма для примера:
Теперь давайте запустим проверку валидации при попытке отправить форму:
Эссе о валидации данных
Зачем нужна валидация данных?
Казалось бы, «невалидные» данные, не удовлетворяющие определённым ограничениям, могут вызвать сбой в работе программы. Но что это означает? Предположим, в каком-то месте программы возникает исключение при попытке преобразовать строку в число, если строка имеет некорректный формат. Разумеется, если исключение не будет нигде перехвачено, это может привести к аварийному завершению программы. Но это маловероятный сценарий развития событий. Скорее всего в каком-то месте сработает перехватчик, который либо выдаст пользователю какое-то сообщение об ошибке в программе, либо сделает запись в журнал ошибок, после чего программа постарается восстановиться от сбоя и продолжить работу. То есть даже если валидацию не выполнять, вполне вероятно, что ничего страшного не случится.
Где и когда выполнять валидацию данных?
Как уже было сказано выше, с точки зрения уменьшения нагрузки лучше всего вообще не выполнять валидацию данных.
Но если всё-таки проверка нужна, логика подсказывает, что удобно проверять данные в том месте, где они попадают в программу из внешнего мира. После такой проверки можно быть уверенным, что в программу попадают правильные данные и в дальнейшем они могут использоваться без дополнительных проверок.Это может быть пользовательский интерфейс, через который человек вводит данные. Это может быть файл, содержащий настройки программы или данные, которые программа должна обработать. Это может быть база данных, в которую информация может попадать из других программ. Это может быть сетевой протокол обмена данными с другими программами. Наконец, это может быть программный интерфейс, который использует другая программа, вызывая некоторые функции/процедуры и передавая в них параметры.
Как выполнять валидацию данных?
Какой способ валидации следует применять на практике в том или ином случае? Чаще всего одним способом ограничиться не удаётся, да и не нужно. Валидацию данных можно и нужно выполнять в несколько этапов, усложняя проверки.
Сначала, по мере ввода, следим за тем, чтобы данные не содержали недопустимых символов. Например, для числового поля пользователю может быть запрещён ввод нецифровых символов.
После того, как ввод завершён, можно проверить всё значение целиком. Для введённого числа могут быть какие-то ограничения, например, оно не должно превышать определённого максимального допустимого значения. Если наше числовое поле представляет собой возраст, оно должно находиться в пределах от 0 до, скажем, 120.
Когда заполнены все поля, можно проверить, согласованы ли введённые значения друг с другом. Например, если в форме кроме поля для указания возраста есть поле для ввода номера паспорта, приложение может проверить, что при заполнении номера паспорта возраст должен быть не менее 14 лет.
Наконец, если всё введено корректно, можно попытаться начать обработку, выполняя проверки по ходу дела, а также в самом конце, и если что-то пошло не так, выполнить откат к исходному состоянию.
Ну и, конечно же, проверки на следующем уровне могут подстраховывать проверки предыдущих уровней. Скажем, для веб-приложений обязательной является проверка данных, пришедших на сервер в HTTP-запросе, независимо от того, выполнялась ли перед этим предварительная валидация в браузере или нет. Причина этого в том, что проверку на клиентской стороне можно обойти. Для других видов приложений обойти проверки не так просто, но иногда тоже вполне возможно, как показано в примере чуть ниже.
Тестирование валидаторов
Завершим статью демонстрацией различных видов валидаторов, а также некоторыми рекомендациями относительно того, как при тестировании проверять правильность их работы.
Начнём с посимвольной проверки. Графический редактор Paint, диалог изменения размеров рисунка, ширина рисунка. В это поле допускается вводить только цифры, при попытке ввести другие символы выдаётся сообщение об ошибке:
Однако, проявив смекалку, можно обойти эту валидацию вводимых символов: через буфер обмена удаётся вставить в это поле отрицательное число, несмотря на то, что минус является недопустимым символом:
Впрочем, это не приводит к негативным последствиям, потому что на следующем уровне стоит ещё одна проверка, которая срабатывает при нажатии кнопки OK:
Есть и другие ограничения для этого поля, которые тоже проверяются после нажатия кнопки OK:
А вот находящееся совсем рядом в том же диалоге поле для ввода наклона рисунка не содержит валидации символов, несмотря на то, что это тоже числовое поле. Более того, при вводе недопустимых символов после нажатия OK можно увидеть вот такое странное сообщение, практически не поддающееся расшифровке:
Все вышеописанные примеры связаны с проверкой отдельно взятого поля. Пример валидации комбинации полей можно найти в том же приложении, но в другом месте — в диалоге настройки параметров страницы для печати. Если указать размеры полей страницы так, чтобы в сумме они превосходили ширину страницы, получим вот такое сообщение:
Ну и, наконец, в заметке «Почему не хватает памяти, чтобы уменьшить размеры рисунка?» описана ошибка, связанная с тем, что в этом графическом редакторе отсутствует корректная обработка сбоев и откат транзакции при слишком сильном увеличении размера рисунка.
Тестировщику необходимо все эти ситуации отрабатывать. Во-первых, нужно проверять валидацию на всех уровнях. Во-вторых, нужно проверять согласованность валидаторов на разных уровнях. В-третьих, надо искать пути обхода валидаторов, пытаясь добраться до следующего уровня без предварительных проверок.
Заключение
Большая часть этой статьи посвящена не способам тестирования валидаторов, а описанию их устройства. Почему? Потому что врага надо знать в лицо. Чтобы найти дефект валидации данных, надо понимать, где искать и на что обращать внимание.
Валидация
Валидация — это проверка значений, указанных пользователем, и отображение найденных ошибок.
Описанное здесь поведение валидаций и отображение ошибок реализовано в библиотеке «React UI Validations», по возможности используйте эту библиотеку в продукте.
Принципы
Валидация на только что открытой пустой форме запрещена. Исключение — черновики, когда пользователь уже заполнял эту форму, через какое-то время вернулся к ней, а она заполнена с ошибками.
Виды валидации
Существует три вида валидаций: мгновенная, по потере фокуса и по отправке формы.
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Самый быстрый способ сообщить об ошибке — мгновенная валидация. Но она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Обычно такие ошибки связаны с неправильной раскладкой клавиатуры (кириллица вместо латиницы) или вводом букв в цифровое поле (ИНН, КПП и др.) Для этих случаев мы используем поля с масками: ввод неподходящих символов в них заблокирован. Поэтому в наших интерфейсах есть только два вида валидации:
Валидация по потере фокуса
Когда использовать
Этот вид валидации подходит для большинства случаев.
Как работает
Не валидируйте поля на пустоту по потере фокуса — не показывайте ошибку если поле не заполнено, возможно пользователь вернется и заполнит поле чуть позже. Показывать ошибку в таких случаях можно только после отправки формы.
Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено. Если найдена ошибка, поле подсвечивается красным. Фокус в это поле автоматически не возвращается:
Текст ошибки появляется в тултипе, когда поле получает наведение или фокус:
Поле с ошибкой должно остаться подсвеченным, если оно получило фокус, его значение не исправляли, а затем оно потеряло фокус.
Красная подсветка снимается с поля, как только пользователь начал исправлять ошибочное значение.
Валидация при отправке формы
Когда использовать
Используйте этот вид валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей.
Как работает
Проверка происходит после того, как пользователь нажал кнопку отправки данных: все поля с ошибками на форме подсвечиваются, страница прокручивается к первому полю с ошибкой, фокус перемещается в это поле, курсор встает в конец строки, рядом с полем появляется тултип с подсказкой.
При прокрутке к первому полю от верхней границы окна до ошибочного поля остается отступ 48px — шесть модулей.
Блокирование кнопки отправки
В небольших формах вместо проверки заполнения обязательных полей можно блокировать кнопку отправки формы. Используйте это поведение, когда очевидно, почему кнопка отправки формы неактивна. Например, на форме входа:
Как только заполнены все обязательные поля — кнопка становится активной. Если после этого пользователь стер значение в одном из полей — кнопка снова должна стать не активной.
Сообщения об ошибках
Об ошибках можно сообщать двумя способами:
Из этих двух способов мы рекомендуем использовать тултипы. Они идут отдельным слоем, поэтому не раздвигают форму и легко размещаются, даже если поля на форме расположены плотно.
Тултипы
Как работают
Тултип с подсказкой появляется в двух случаях:
Если значение в поле с ошибкой было изменено, потеряло фокус, а потом заново оказалось в фокусе — тултип с текстом старой ошибки уже не возникает. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Тултип исчезает, когда:
Тултип по наведению перекрывает тултип по фокусу.
Тултип может появляться сверху или справа от контрола с ошибкой, так чтобы он не перекрывал полезную информацию:
Единообразие поведения и внешнего вида
Показывайте тултипы справа от полей. Eсли в этом случае они перекрывают важное содержимое на странице, выводите тултипы сверху. Придерживайтесь единообразия, но помните, что контент важнее него.
Красные тексты на странице
Как работают
Красный текст ошибки появляется сразу, как только произошла валидация и ошибочное поле подсветилось.
Как только пользователь начал исправлять значение, красная подсветка поля исчезает, и цвет текста ошибки меняется на черный — #333.
Текст ошибки пропадает по потере фокуса и больше не появляется, если поле заново получает фокус. Это правило одинаково работает для всех типов валидаций: и по потере фокуса, и при отправке формы.
Выводите текст ошибки справа, если на форме есть место, а само сообщение короткое. Так форму не придется раздвигать, чтобы показать ошибку.
Если справа от поля нет места для текста, раздвигайте форму и выводите сообщение под полем.
На более сложных формах выводите сообщение об ошибке в тултипе.
Валидация зависимых полей
Зависимые поля — это поля, значение которых зависит друг от друга.
Ошибки, которые связаны с нарушением зависимости полей, мы показываем после сабмита формы. Например, ИНН и КПП. Если пользователь указал ИНН из 10 цифр, а поле с КПП оставил пустым, после отправки формы пустое поле с КПП будет подсвечено.
ИНН может быть двух видов:
Если пользователь указал ИНН из 12 цифр, значит организация — индивидуальный предприниматель, и у нее нет КПП, значит поле КПП заполнять не нужно. И наоборот, если заполнено КПП, а ИНН указан 12-значный, возможно неверно указан ИНН.
Подсветка зависимых полей пропадает, как только пользователь начал исправлять значение в одном из этих полей.
Если при заполнении зависимого поля нарушен формат значения, сообщайте о такой ошибке при потере фокуса. Например, пользователь ввел 3 цифры в поле ИНН и убрал фокус. Такое поле должно подсветиться сразу же.
Пример
Есть форма из 5 полей:
Пользователь пропустил поле с названием организации, заполнил ИНН значением из 10 цифр, перешел в поле почты, указал некорректный адрес, перешел в поле с телефоном и указал некорректный номер, но из поля пока не ушел:
Пользователь навел курсор на поле с почтой, появился тултип. Но исправлять значение пользователь не стал:
Пользователь нажал кнопку «Отправить» — фокус перешел в поле «Название организации», так как оно обязательное и незаполненное:
Поле с телефоном также подсветилось красным, так как заполнено некорректно. ИНН и КПП подсветились, так как ИНН состоит из 10 цифр, значит должен быть заполнен и КПП — валидация зависимых полей произошла только после отправки формы.
Пользователь начинает вводить название организации, подсветка поля гаснет, а текст подсказки остается:
Заполнил название организации, перешел в поле ИНН:
Понял, что ИНН правильный, и нужно заполнить КПП:
Начал заполнять поле КПП. Красная рамка у ИНН и КПП исчезла — пользователь изменил значение в одном из зависимых полей:
Заполнил КПП, перешел в следующее поле:
Исправил почту, перешел в следующее поле:
Исправил телефон, кликнул за пределами поля:
Теперь по нажатию кнопки «Отправить» все будет хорошо.
Реализованный пример этой формы можно посмотреть в библиотеке валидаций.
Что такое валидация
Основные определения
Это процесс проверки данных, введенных пользователем, на соответствие заданным критериям (например, на отсутствие ошибок в данных).
Это введенная пользователем информация, которая будет провалидирована (ФИО, адрес, город, номер телефона, ИНН и др.).
Требования, которым должны соответствовать введенные данные (номер мобильного телефона должен состоять из 11 цифр, имя должно быть написано латинскими буквами и т.д.)
Задача валидации
Основной задачей валидации является предоставление полнофункционального инструмента валидации форм в целом и отдельных контролов ввода. Валидация осуществляет проверку данных на их корректность.
Предмет валидации — данные, а не визуальные контролы. Логика в том, чтобы валидировать не контрол, а значение, которое будет записано в этот контрол. Валидация позволяет проверить данные до того, как они будут отправлены на сервер.
Виды валидации
В Wasaby существует три вида запуска валидации:
Чем раньше интерфейс сообщает об ошибке, тем лучше — пользователю проще вернуться и исправить ошибку.
Соответственно, самый быстрый способ сообщить об ошибке — мгновенная валидация. Она возможна только в тех случаях, когда в процессе ввода понятно, что значение некорректное. Чаще всего, такие ошибки связаны с неправильной раскладкой клавиатуры или вводом букв в цифровое поле (ИНН, номер телефона и другие). Для этих случаев обычно используют поля с масками: ввод неподходящих символов в них заблокирован.
Валидация при потере фокуса — основной вид запуска валидации. Валидация срабатывает сразу после потери фокуса, если значение в поле заполнено.
Валидация при отправке формы — для тех случаев, когда запуск валидации по потере фокуса невозможен. Используйте этот вид запуска валидации, когда нельзя проверить поля по потере фокуса. Например, для проверки заполнения обязательных полей. Проверка происходит после того, как пользователь нажал кнопку отправки данных.
Валидация на клиенте и на сервере
Общий алгоритм валидации данных, введенных пользователем, можно представить следующим образом:
Даже если данные будут проверены на клиенте, на сервере они должны будут пройти повторную проверку.
| Преимущества | Недостатки | |
|---|---|---|
| Клиент | Валидация данных на клиенте позволяет произвести предварительную проверку данных без отправки их на сервер. Процесс проверки будет быстрым, пользователь моментально увидит результат. Такая валидация позволяет избежать «забивания» канала передачи данных. | У злоумышленников есть доступ к процессу валидации, соответственно, проверка данных на клиенте является небезопасной. |
| Сервер | Процесс валидации безопасен, поскольку доступа к валидации на сервере у злоумышленников нет. | Если валидировать данные только на сервере, канал передачи данных может быть перегружен лишними запросами, поскольку данные каждый раз будут перемещаться между клиентом и сервером. |
Итак, проверка на стороне клиента хороша для ускорения обратной связи с клиентами. Однако она недостаточна, поскольку ее объем действия очень ограничен. Проверка выполняется только в пользовательском интерфейсе браузера. Проверка на стороне сервера является обязательной, поскольку проверка на стороне клиента не гарантирует, что на сервер будут поступать неподтвержденные данные.
Контролы с внутренней валидацией
Часть контролов поддерживают внутреннюю валидацию. Например, Controls/date:BaseInput и Controls/dateRange:Input проверяют корректность введенных данных и показывают сообщение, если данные введены неправильно.
Такие контролы имеют внутри себя встроенный контейнер валидации и их можно не оборачивать внешним.
Валидаторы для Controls/date:BaseInput передаются во внутренний контейнер валидации с помощью опции valueValidators, которая содежит массив валидаторов. Валидаторы проверяют значение опции value.
У Controls/dateRange:Input есть две опции startValueValidators и endValueValidators, которые содержат массивы валидаторов. Валидаторы проверяют значение опций startValue и endValue соотвественно.