Laravel поставляется с простой, удобной системой валидации (проверки входных данных на соответствие правилам) и получения сообщений об ошибках - классом Validation .
Первый параметр, передаваемый методу make - данные для проверки. Второй параметр - правила, которые к ним должны быть применены.
Несколько правил могут быть разделены либо прямой чертой (|), либо быть отдельными элементами массива.
$validator = Validator::make(array("name" => "Дейл"), array("name" => array("required", "min:5")));
Как только был создан экземпляр Validator , метод fails (или passes) может быть использован для проведения проверки.
If ($validator->fails()) { // Переданные данные не прошли проверку }
Если Validator нашёл ошибки, вы можете получить его сообщения таким образом:
$messages = $validator->messages();
Вы также можете получить массив правил, данные которые не прошли проверку, без самих сообщений:
$failed = $validator->failed();
Класс Validator содержит несколько изначальных правил для проверки файлов, такие как size , mimes и другие. Для выполнения проверки над файлами просто передайте эти файлы вместе с другими данными.
Laravel после завершения валидации может запустить вашу функцию-замыкание, в которой вы можете, например, проверить что-то особенное или добавить какое-то своё сообщение об ошибке. Для этого служит метод after() :
$validator = Validator::make(...); $validator->after(function($validator) { if ($this->somethingElseIsInvalid()) { $validator->errors()->add("field", "Something is wrong with this field!"); } }); if ($validator->fails()) { // }
Вы можете добавить несколько after , если это нужно.
Писать полный код валидации каждый раз, когда нужно провалидировать данные - это неудобно. Поэтому Laravel предоставляет несколько решений для упрощения этой процедуры.
Базовый контроллер App\Http\Controllers\Controller включает в себя трейт ValidatesRequests , который уже содержит методы для валидации:
/** * Сохранить пост в блоге. * * @param Request $request * @return Response */ public function store(Request $request) { $this->validate($request, [ "title" => "required|unique|max:255", "body" => "required", ]); // }
Если валидация проходит, код продолжает выполняться. Если нет - бросается исключение Illuminate\Contracts\Validation\ValidationException . Если вы не поймаете это исключение, его поймает фреймворк, заполнит flash-переменные сообщениями об ошибках валидации и средиректит пользователя на предыдущую страницу с формой - сам!
В случае AJAX-запроса редиректа не происходит, фреймворк отдает ответ с HTTP-кодом 422 и JSON с ошибками валидации.
Код, приведенный выше, аналогичен вот этому::
/** * Сохранить пост в блоге. * * @param Request $request * @return Response */ public function store(Request $request) { $v = Validator::make($request->all(), [ "title" => "required|unique|max:255", "body" => "required", ]); if ($v->fails()) { return redirect()->back()->withErrors($v->errors()); } // }
Если вы хотите кастомизировать сообщения об ошибках валидации, которые сохраняются во флэш-переменных сессии при редиректе, перекройте метод formatValidationErrors в вашем контроллере:
/** * {@inheritdoc} */ protected function formatValidationErrors(\Illuminate\Validation\Validator $validator) { return $validator->errors()->all(); }Для реализации более сложных сценариев валидации вам могут быть удобны так называемые Form Requests. Это специальные классы HTTP-запроса, содержащие в себе логику валидации. Они обрабатывают запрос до того, как он поступит в контроллер.
Чтобы создать класс запроса, используйте artisan-команду make:request:
Php artisan make:request StoreBlogPostRequest
Класс будет создан в папке app/Http/Requests . Добавьте необходимые правила валидации в его метод rules:
/** * Get the validation rules that apply to the request. * * @return array */ public function rules() { return [ "title" => "required|unique|max:255", "body" => "required", ]; }
Для того, чтобы фреймворк перехватил запрос перед контроллером, добавьте этот класс в аргументы необходимого метода контроллера:
При грамотном использовании валидации запросов вы можете быть уверены, что в ваших контроллерах всегда находятся только отвалидированные входные данные!
В случае неудачной валидации фреймворк заполняет флэш-переменные ошибками валидации и возврашает редирект на предыдущую страницу. В случае AJAX-запроса отдается ответ с кодом 422 и JSON с ошибками валидации.
Классы Form Request также содержат метод authorize . В этом методе вы можете проверять, разрешено ли пользователю совершать это действие, обновлять данный ресурс. Например, если пользователь пытается отредактировать комментарий к посту, является ли он его автором?
/** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { $commentId = $this->route("comment"); return Comment::where("id", $commentId) ->where("user_id", Auth::id())->exists(); }
Обратите внимание на вызов метода route() выше. Этод метод дает вам доступ к параметрам в урле (в данном случае это {comment}), определенным в роуте:
Route::post("comment/{comment}");
Если метод authorize возвращает false, фреймворк формирует ответ с HTTP-кодом 403 и сразу же отсылает его. Метод контроллера не выполняется.
/** * Determine if the user is authorized to make this request. * * @return bool */ public function authorize() { return true; }
Если вы хотите кастомизировать сообщения об ошибках валидации, которые сохраняются во флэш-переменных сессии при редиректе, переопределите метод formatValidationErrors в базовом классе запросов (App\Http\Requests\Request):
/** * {@inheritdoc} */ protected function formatValidationErrors(\Illuminate\Validation\Validator $validator) { return $validator->errors()->all(); }После вызова метода messages объекта Validator вы получите объект MessageBag , который имеет набор полезных методов для доступа к сообщениям об ошибках.
Примечание: по умолчанию сообщения форматируются в вид, который подходит для Twitter Bootstrap.
Как только вы провели проверку, вам понадобится простой способ, чтобы передать ошибки в шаблон. Laravel позволяет удобно сделать это. Например, у нас есть такие роуты:
Route::get("register", function() { return View::make("user.register"); }); Route::post("register", function() { $rules = array(...); $validator = Validator::make(Input::all(), $rules); if ($validator->fails()) { return redirect("register")->withErrors($validator); } });
Заметьте, что когда проверки не пройдены, мы передаём объект Validator объекту переадресации Redirect с помощью метода withErrors . Этот метод сохранит сообщения об ошибках в одноразовых flash-переменных сессии, таким образом делая их доступными для следующего запроса.
Однако, заметьте, мы не передаем в View::make("user.register"); переменные $errors в шаблон. Laravel сам проверяет данные сессии на наличие переменных и автоматически передает их шаблону, если они доступны. Таким образом, важно помнить, что переменная $errors будет доступна для всех ваших шаблонов всегда, при любом запросе. . Это позволяет вам считать, что переменная $errors всегда определена и может безопасно использоваться. Переменная $errors - экземпляр класса MessageBag .
Таким образом, после переадресации вы можете прибегнуть к автоматически установленной в шаблоне переменной $errors:
first("email"); ?>
Если у вас есть несколько форм на странице, то вы можете выбрать имя объекта MessageBag, в котором будут возвращаться тексты ошибок, чтобы вы могли их корректно отобразить для нужной формы.
Return redirect("register")->withErrors($validator, "login");
Получить текст ошибки из MessageBag с именем login:
login->first("email"); ?>
Ниже список всех доступных правил и их функции:
Поле должно быть в значении yes , on или 1 . Это полезно для проверки принятия правил и лицензий.
Поле должно быть корректным URL, доступным через функцию checkdnsrr .
Поле должно быть датой, более поздней, чем date
Поле должно содержать только алфавитные символы.
Поле должно содержать только алфавитные символы, цифры, знаки подчёркивания (_) и дефисы (-).
Поле должно содержать только алфавитные символы и цифры.
Поле должно быть массивом.
Поле должно быть датой, более ранней, чем date . Строки приводятся к датам функцией strtotime .
Поле должно иметь размер в диапазоне от min до max . Строки, числа и файлы трактуются аналогично правилу size .
Поле должно быть логическим (булевым). Разрешенные значения: true , false , 1 , 0 , "1" и "0" .
Значение поля должно соответствовать значению поля с этим именем, плюс foo_confirmation . Например, если проверяется поле password , то на вход должно быть передано совпадающее по значению поле password_confirmation .
Поле должно быть правильной датой в соответствии с функцией strtotime .
Поле должно подходить под формат даты format в соответствии с функцией date_parse_from_format .
Значение проверяемого поля должно отличаться от значения поля field .
Поле должно быть корректным адресом e-mail.
Поле должно существовать в заданной таблице базе данных.
Простое использование:
"state" => "exists:states"
Указание имени поля в таблице:
"state" => "exists:states,abbreviation"
Вы также можете указать больше условий, которые будут добавлены к запросу "WHERE":
"email" => "exists:staff,email,account_id,1"
Загруженный файл должен быть изображением в формате jpeg, png, bmp, gif или svg.
Значение поля должно быть одним из перечисленных (foo , bar и т.д.).
Поле должно иметь корректное целочисленное значение.
Поле должно быть корректным IP-адресом.
Значение поля должно быть меньше или равно value
MIME-тип загруженного файла должен быть одним из перечисленных.
Простое использование:
"photo" => "mimes:jpeg,bmp,png"
Значение поля должно быть более value . Строки, числа и файлы трактуются аналогично правилу .
Значение поля не должно быть одним из перечисленных (foo , bar и т.д.).
Поле должно иметь корректное числовое или дробное значение.
Поле должно соответствовать заданному регулярному выражению.
Внимание: при использовании этого правила может быть нужно перечислять другие правила в виде элементов массива, особенно если выражение содержит символ вертикальной черты (|).
Проверяемое поле должно присутствовать и иметь непустое значение.
Проверяемое поле должно присутствовать и иметь непустое значение, если другое поле field присутствует и имеет любое из значений value .
Присутствует и имеет непустое значение хотя бы одно из перечисленных полей (foo , bar и т.д.).
Проверяемое поле должно присутствовать и иметь непустое значение, но только если присутствуют и имеют непустое значение все перечисленные поля (foo , bar и т.д.).
Проверяемое поле должно присутствовать и иметь непустое значение, но только если не присутствует или имеет пустое значение хотя бы одно из перечисленных полей (foo , bar и т.д.).
Проверяемое поле должно присутствовать и иметь непустое значение, но только если не присутствуют или имеют пустые значения все перечисленные поля (foo , bar и т.д.).
Поле должно иметь то же значение, что и поле field .
Поле должно иметь совпадающий с value размер. Для строк это обозначает длину, для чисел - число, для файлов - размер в килобайтах.
Поле должно содержать идентификатор часового пояса (таймзоны), один из перечисленных в php-функции timezone_identifiers_list
Значение поля должно быть уникальным в заданной таблице базы данных. Если column не указано, то будет использовано имя поля.
Вы также можете указать больше условий, которые будут добавлены к запросу "WHERE"":
"email" => "unique:users,email_address,NULL,id,account_id,1"
В правиле выше только строки с account_id равном 1 будут включены в проверку.
Поле должно быть корректным URL.
Примечание: используется PHP-функция filter_var
Иногда вам нужно валидировать некое поле только тогда, когда оно присутствует во входных данных. Для этого добавьте правило sometimes:
$v = Validator::make($data, array("email" => "sometimes|required|email",));
В примере выше для поля email будет запущена валидация только когда $data["email"] существует.
Иногда вам нужно, чтобы поле имело какое-либо значение только если другое поле имеет значеие, скажем, больше 100. Или вы можете требовать наличия двух полей, только когда также указано третье. Это легко достигается условными правилами. Сперва создайте объект Validator с набором статичных правил, которые никогда не изменяются:
$v = Validator::make($data, array("email" => "required|email", "games" => "required|numeric",));
Теперь предположим, что ваше приложение написано для коллекционеров игр. Если регистрируется коллекционер с более, чем 100 играми, то мы хотим их спросить, зачем им такое количество. Например, у них может быть магазин или может им просто нравится их собирать. Итак, для добавления такого условного правила мы используем метод Validator .
$v->sometimes("reason", "required|max:500", function($input) { return $input->games >= 100; });
Первый параметр этого метода - имя поля, которое мы проверяем. Второй параметр - правило, которое мы хотим добавить, если переданная функция-замыкание (третий параметр) вернёт true . Этот метод позволяет легко создавать сложные правила проверки ввода. Вы можете даже добавлять одни и те же условные правила для нескольких полей одновременно:
$v->sometimes(array("reason", "cost"), "required", function($input) { return $input->games >= 100; });
Примечание: Параметр $input , передаваемый замыканию - объект Illuminate\Support\Fluent и может использоваться для чтения проверяемого ввода и файлов.
Вы можете передать собственные сообщения об ошибках вместо используемых по умолчанию. Есть несколько способов это сделать.
Примечание: строка:attribute будет заменена на имя проверяемого поля. Вы также можете использовать и другие строки-переменные.
Иногда вам может потребоваться указать своё сообщение для отдельного поля.
$messages = array("email.required" => "Нам нужно знать ваш e-mail адрес!",);
Также можно определять сообщения валидации в файле локализации вместо того, чтобы передавать их в Validator напрямую. Для этого добавьте сообщения в массив custom файла локализации app/lang/xx/validation.php .
"custom" => array("email" => array("required" => "Нам нужно знать ваш e-mail адрес!",),),
Laravel изначально содержит множество полезных правил, однако вам может понадобиться создать собственные. Одним из способов зарегистрировать произвольное правило - через метод Validator::extend .
Validator::extend("foo", function($attribute, $value, $parameters) { return $value == "foo"; });
Примечание: имя правила должно быть в формате_с_подчёркиваниями.
Переданная функция-замыкание получает три параметра: имя проверяемого поля $attribute , значение поля $value и массив параметров $parameters , переданных правилу.
Вместо функции в метод extend можно передать ссылку на метод класса:
Validator::extend("foo", "FooValidator@validate");
Обратите внимание, что вам также понадобится определить сообщение об ошибке для нового правила. Вы можете сделать это либо передавая его в виде массива строк в Validator , либо вписав в файл локализации.
Вместо использования функций-замыканий для расширения набора доступных правил вы можете расширить сам класс Validator . Для этого создайте класс, который наследует Illuminate\Validation\Validator . Вы можете добавить новые методы проверок, начав их имя с validate .
Затем вам нужно зарегистрировать это расширение валидации. Сделать это можно, например, в вашем сервис-провайдере или в ваших старт-файлах .
Validator::resolver(function($translator, $data, $rules, $messages) { return new CustomValidator($translator, $data, $rules, $messages); });
Иногда при создании своего класса валидации вам может понадобиться определить собственные строки-переменные (типа ":foo") для замены в сообщениях об ошибках. Это делается путём создания класса, как было описано выше, и добавлением функций с именами вида replaceXXX .
Protected function replaceFoo($message, $attribute, $rule, $parameters) { return str_replace(":foo", $parameters, $message); }
Если вы хотите добавить свое сообщение без использования Validator::extend , вы можете использовать метод Validator::replacer:
Validator::replacer("rule", function($message, $attribute, $rule, $parameters) { // });
От автора: Когда вы собираете информацию от пользователей с помощью формы, использование хоть какой-то валидации данных является обязательным моментом. Если не обратить внимание на данный момент, то это может привести к потере покупателей, порче данных в базе данных (БД) и даже к появлению брешей в безопасности вашего веб-сайта. Так исторически сложилось, что валидация форм всегда вызывала головную боль. На стороне сервера это осуществить легче благодаря полноценным фреймворкам, которые сделают все за вас, но на стороне клиента это чаще всего заканчивается использованием JavaScript библиотек, которые отнимают немало усилий для их интеграции.
К счастью, HTML5 предоставляет несколько возможностей, которые способны решить большую часть вопросов, связанных с валидацией форм. Формы в HTML5 теперь имеют встроенную поддержку для валидации через использование специальных атрибутов и новых типов элемента input. А это также дает вам больше контроля над оформлением форм через CSS.
Посмотрите на онлайн-пример валидации формы и прочитайте небольшую шпаргалку по основам валидации форм в HTML5.
В HTML5 представлены несколько новых типов элемента input. Они могут быть использованы для создания полей ввода, которые будут принимать только определенный вид данных. Вот новые типы, которые появились в HTML5:
Чтобы использовать один из новых типов, укажите его название в качестве значения у атрибута type:
< input type = "email" / > |
Если браузер не поддерживает данный тип элемента input, то текущий элемент будет вести себя, как обычное текстовое поле ввода. Также, вам будет полезно узнать о том, что некоторые типы полей (например, «email» и «tel») приводят к открытию на мобильных устройствах специальных клавиатур с ограниченным набором клавиш, а не полной раскладки QWERTY. Более подробную информацию обо всех типах элемента input вы найдете на сайте MDN – .
Простое добавление атрибута «required» для элемента input, select или textarea сообщит браузеру о том, что у данного поля должно быть значение. Воспринимайте это, как красную звездочку*, которую мы видим в большинстве регистрационных форм.
< input type = "checkbox" name = "terms" required > |
Проблема здесь заключается в том, что практически любая информация будет удовлетворять данному требованию, т.е., например, вы можете пройти валидацию, просто поставив пробел (мы покажем вам, как этого избежать).
Когда вы указываете атрибут required для полей типа email или url, браузер ожидает наличия определенного шаблона, по которому он сможет проверить информацию, но подобная проверка очень снисходительна и пропускает e-mail адреса вроде «z@zz» (читайте далее, чтобы узнать, как с этим бороться).
Мы можем установить базовые ограничения, такие как максимальная длина или минимальное и максимальное значение для числовых полей. Чтобы ограничить длину элементов input или textarea, используйте атрибут «maxlength». Это делается для того, чтобы вообще нельзя было ввести строку длиннее, чем значение атрибута «maxlength». Если вы попробуете вставить строку, которая превышает лимит, то форма просто обрежет ее.
CSS3 псевдо-классы позволяют нам оформить любое поле формы в зависимости от его состояния. Вот данные псевдо-классы:
Это означает, что обязательные поля у вас могут выглядеть одним образом, необязательные - другим и т.д. В нашем демо-примере мы скомбинировали селекторы «valid» и «invalid» с псевдо-классом «focus», чтобы раскрасить поля формы в красный и зеленый цвета, когда пользователь выбирает их и начинает в них что-нибудь вводить.
input:focus:invalid, textarea:focus:invalid{ border:solid 2px #F5192F; } input:focus:valid, textarea:focus:valid{ border:solid 2px #18E109; background-color:#fff; }
input : focus : invalid , textarea : focus : invalid { border : solid 2px #F5192F; input : focus : valid , textarea : focus : valid { border : solid 2px #18E109; background - color : #fff; |
Вы наверняка замечали, что когда вы пытаетесь отправить неправильно заполненную форму, появляются всплывающие подсказки. Задав для наших полей атрибут «title» мы можем добавить дополнительные подсказки о том, каких значений наши правила валидации ожидают от пользователя.
Обратите внимание на то, что разные браузеры по-своему отображают всплывающие подсказки. В браузере Chrome значение атрибута title появится под основным текстом сообщения об ошибке и будет иметь меньший размер шрифта, чем текст об ошибке. Браузер Firefox вообще не будет отображать ваш текст для всплывающей подсказки до тех пор, пока вы не будете использовать атрибут «pattern», который будет использован для информации о шаблоне.
Валидация форм
Поля в форме предназначены для сбора информации от посетителей страницы. Но несмотря на все усилия и объяснения, получение правильной информации может оказаться трудным делом. Нетерпеливые или невнимательные посетители могут пропускать важные поля, заполнять поле или несколько полей не полностью, да и попросту нажимать неправильные клавиши. Заполнив таким образом форму, они нажимают кнопку "Отправить", и серверная программа получает набор данных, с которыми она не знает что делать (если не реализована валидация данных на серверной стороне).
Серьезной веб-странице требуется проверка данных, т.е. какой-либо способ обнаружения ошибок во введенных данных, а еще лучше - способ, не допускающий ошибок вообще. На протяжении многих лет веб-разработчики делали это с помощью процедур JavaScript собственной разработки или посредством профессиональных библиотек JavaScript. И говоря по правде, эти подходы давали отличные результаты.
Но, видя, что проверка выполняется повсеместно (практически всем нужно проверять вводимые данные на ошибки) и применяется лишь к нескольким основным типам данных (например, адресам электронной почты или датам), а также, что ее реализация - такая неинтересная и скучная задача (никому, по сути, не хочется писать один и тот же код для каждой формы, не говоря уже о тестировании его), определенно должен быть лучший способ для ее реализации.
Создатели HTML5 смогли увидеть эту надобность и изобрели способ привлечь браузеры на помощь, переложив задачу проверки с плеч веб-разработчиков на веб-обозреватели. Создатели HTML5 разработали систему проверки на стороне клиента, которая позволяет вставлять основные правила валидации в любое поле . Лучшее в этой системе - это ее простота и легкость: все, что нужно сделать - так это вставить правильный атрибут.
Основная идея в основе проверки форм HTML5 состоит в том, что разработчик указывает данные для валидации, но не реализует все необходимые для этого трудоемкие подробности. Это что-то похожее на начальника, который только отдает приказания, но реализует эти указания не сам, а с помощью подчиненных.
Например, допустим, что определенное поле нельзя оставлять пустым, и посетитель должен ввести в него хоть что-то. В HTML5 это осуществляется с помощью атрибута required в соответствующем поле (далее дорабатываем пример из предыдущей статьи):
Даже с применением для поля атрибута required на это требование нет никаких визуальных указателей по умолчанию. Поэтому следует обратить внимание пользователя на это требование с помощью каких-либо своих визуальных признаков, например, выделив рамку поля цветом и поставив возле него звездочку.
Проверка выполняется, когда пользователь нажмет кнопку для отправки формы. Если браузер поддерживает формы HTML5, он заметит пустое обязательное для заполнения поле, перехватит вызов отправки формы и отобразит всплывающее сообщение об ошибке:
Хотя официальных требований к оформлению сообщения об ошибках при проверке не существует, во всех браузерах для этой цели применяются всплывающие подсказки. К сожалению, веб-разработчики не могут изменять оформление или текст этого сообщения (без использования JavaScript), по крайней мере в настоящее время.
Возникает еще один вопрос: что будет, если нарушено несколько правил проверки, например, не заполнено несколько обязательных полей?
Опять же, ничего не будет, пока пользователь не нажмет кнопку для отправки формы. Только после этого браузер начнет проверять поля сверху вниз. Встретив первое некорректное значение, он прекращает дальнейшую проверку, отменяет отправку формы и выводит сообщение об ошибке рядом с полем, вызвавшим эту ошибку. (Кроме этого, если при заполнении формы область с полем ошибки вышла за пределы экрана, браузер прокручивает экран, чтобы это поле находилось вверху страницы.) После того как пользователь исправит данную ошибку и опять нажмет кнопку для отправки формы, браузер остановится на следующей ошибке ввода и процесс повторится.
В некоторых случаях может потребоваться отключить проверку. Например, вы хотите протестировать свой серверный код на правильность обработки поступивших некорректных данных. Чтобы отключить проверку для всей формы, в элемент
Из плюсов это конечно автоматическая проверка, из минусов можно отметить то, что старые браузеры не поддерживают HTML5.
Если добавить атрибут required : то данное поле должно быть обязательно заполнено, иначе появится предупреждение.
Если добавить атрибут placeholder то его значение появится в поле в роли подсказки, например:
Проверить поддержку какого-то параметра браузером, можно на сайте caniuse.com
Ограничить количество вводимых символов можно свойством maxlength , например:
Параметры min/max ограничивают цифровые значения: . Также это ограничение можно присваивать датам:
Параметр multiple позволяет выбирать несколько файлов с помощью Input=”file” или делает возможным ввод нескольких емэйлов в поле Input=”email”.
Разрешить загрузку только определенных типов файлов можно указав mime-type, например только для PNG:
Или только для любых изображений:
Для mp3 и видео:
Можно также использовать регулярные выражения. Например паттерны:
Поле для ввода только слова Привет: . Если надо сделать возможность ввода Привет и привет, то меняем паттерн так: pattern=”[Пп]ривет”. И так далее. Еще примеры. Прописные буквы: + Плюс означает один или больше. Строчные и прописные +
«Защитой от дурака» называется комплекс мер по пресечению ввода неправильной информации в форме. Например, если в поле требуется ввести положительное число от 0 до 10, то следует проверить, чтобы пользователь не ввёл текст или число, которое не лежит в указанном диапазоне, т.е. число не должно быть меньше нуля и больше десяти.
Почему происходит ввод неправильной информации? Это в основном совершается по трём причинам.
Следует понимать, что точные и правильные формулировки хотя и снижают вероятность возникновения ошибок, но никак не спасают от них. Только технические средства на стороне сервера позволяют получить требуемый результат и избежать ввода неправильной информации. Тем не менее, ревизия или, как её ещё называют, валидация на стороне клиента позволяет быстро проверить данные, вводимые пользователем, на корректность, без отправки формы на сервер. Таким образом экономится время пользователя и снижается нагрузка на сервер. С позиции юзабилити тоже имеются плюсы - пользователь сразу получает сообщение о том, какую информацию он указал неверно и может исправить свою ошибку.
Некоторые поля формы должны быть обязательно заполнены перед их отправкой на сервер. Это, к примеру, относится к форме регистрации, где требуется ввести логин и пароль. Для указания обязательных полей используется атрибут required , как показано в примере 1.
Пример 1. Атрибут required
HTML5 IE 10+ Cr Op Sa Fx
Обязательные поля должны быть заполнены перед отправкой формы, иначе форма на сервер не отправится и браузер выдаст об этом предупреждение. Вид сообщения зависит от браузера, например Chrome выводит всплывающую подсказку, как показано на рис. 1.
Рис. 1. Обязательное поле не заполнено
Исходно имеется два поля, в котором вводимые пользователем данные проверяются автоматически. Это веб-адрес и адрес электронной почты. Браузер Chrome также проверяет на корректность поле с календарными данными, но только потому, что у него не предусмотрен интерфейс выбора календаря щелчком мыши. Для этих элементов характерны следующие правила.
У браузеров несколько различается политика по проверке данных пользователя. К примеру, Opera подставляет протокол http:// перед введённым текстом автоматически, тогда как другие браузеры ждут его от пользователя. Chrome и Opera требуют, чтобы в почтовом адресе была точка, для Firefox она не обязательна.
В примере 2 показана форма с обязательными полями, в которой два поля проверяется браузером.
Пример 2. Корректность данных
HTML5 IE 10+ Cr Op Sa Fx
Opera проверяет элемент формы только при наличии атрибута name.
Что происходит в Opera при вводе неверных данных показано на рис. 2.
Рис. 2. Предупреждение о неправильных данных
Некоторые данные нельзя отнести к одному из видов элементов формы, поэтому для них приходится использовать текстовое поле. При этом их ввод происходит по определённому стандарту. Так, IP-адрес содержит четыре числа разделённых точкой (192.168.0.1), почтовый индекс России ограничен шестью цифрами (124007), телефон содержит код города и конкретное количество цифр часто разделяемых дефисом (391 555-341-42) и др. Браузеру необходимо указать шаблон ввода, чтобы он согласно нему проверял вводимые пользователем данные. Для этого используется атрибут pattern , а его значением выступает регулярное выражение . Некоторые типовые значения перечислены в табл. 1.
В примере 3 просят ввести шестнадцатеричное значение цвета (#ffcc00) и если оно не лежит в этом диапазоне, браузер выводит сообщение об ошибке.
Пример 3. Шаблон ввода
HTML5 IE 10+ Cr Op Sa Fx
На рис. 3 показано предупреждение в браузере Chrome.
Рис. 3. Введённые данные не соответствуют шаблону
Валидация не всегда требуется для формы, к примеру, разработчик пожелает использовать универсальное решение на JavaScript и дублирующая проверка браузером ему уже ни к чему. В подобных случаях необходимо отключить встроенную валидацию. Для этого применяется атрибут novalidate тега
Для аналогичной цели применяется и атрибут formnovalidate , который добавляется к кнопке для отправки формы, в данном случае к тегу . В этом случае форма из примера 4 будет иметь следующий вид.
