Как правило все эти проверки повторяются и Вам приходится писать практически один и тот же код, для валидации POST данных , что приводит к дублирование php кода .
Чтобы этого избежать мною был написан простой класс для валидации POST данных на PHP. Данный класс очень простой и легкий в использовании , и Вы можете использовать его в Ваших скриптах . Называется этот класс Validator .
Сразу скажу , что мой класс похож на библиотеку Form_validation в Codeigniter , только немного модифицированный . Поэтому если Вы знакомы с этой библиотекой , то Вам не составит никакого труда разобраться с моим классом валидации POST данных .
Что мне понравилось в библиотеке Form_validation, так это простота задания полей для валидации и собственно сама валидация . Для меня это стало отправной точкой при разработке своего класса валидации .
Давайте взглянем на небольшой пример использования данного класса
Require_once "validator.php"; $validator = new Validator (); $validator->set_rules("name","Ваше имя",array("required" => "Поле %s обязательно для заполнения ","alpha" => "Поле %s должно содержать только буквы ")); $validator->set_rules("email","Ваш email",array("required" => "Поле %s обязательно для заполнения ","valid_email" => "Поле %s должно содержать правильный email-адрес ")); if($validator->run()){ echo "Валидация прошла успешно "; } else{ echo $validator->get_string_errors(); }
В начале
мы
подключаем
файл
класса
validator.php
к нашем
скрипту
. Далее
создаем
экземпляр
класса
и сохраняем
объект
в переменную
$validator
.
Затем
используя
метод
$validator->set_rules($field, $label, $rules)
задаем
поля
для валидации
.
Данный метод принимает 3 параметра :
После того , как все поля для валидации установлены , запускаем валидатор используя метод $validator->run() . Если валидация прошла успешно , то данный метод вернет значение TRUE , иначе , если есть хоть какие-то ошибки , вернет FALSE .
Для того чтобы получить сообщения об ошибках существует три метода :
По умолчанию сообщения об ошибках оборачиваются в тег . Для того чтобы задать свое оформление используйте метод set_error_delimiters($prefix, $suffix) . Например так:
$validator->set_error_delimiters("","");
Теперь сообщения об ошибках будут оборачиваться в div с классом «error»
Как видите все очень просто .
Для установки правил валидации Вы можете методу set_rules($fields) передать многомерный ассоциативный массив . Давайте посмотрим на пример :
$rules = array(array("field" => "name", "label" => "Ваше имя", "rules" => array("required" => "Поле %s обязательно для заполнения ", "alpha" => "Поле %s должно содержать только буквы ")), array("field" => "email", "label" => "Ваш email", "rules" => array("required" => "Поле %s обязательно для заполнения ", "valid_email" => "Поле %s должно содержать правильный email-адрес "))); $validator->set_rules($rules);
Как видите я записал те же самые правила валидации , что и в первом примере , только в виде многомерного ассоциативного массива . Вы можете использовать любой из способов , который Вам больше подходит в той или иной ситуации .
Итак , какие же правила валидации поддерживает данный класс ?
Я вынес в этот класс наиболее распространенные правила валидации , с которыми сталкивается каждый . Вот полный список этих правил :
required | Возвращает FALSE если поле не заполнено |
integer | Возвращает FALSE если значение не является целым числом |
float | Возвращает FALSE если значение не числового вида |
valid_url | Возвращает FALSE если значения не является корректным URL адресом |
valid_email | Возвращает FALSE если значения не является корректным e-mail адресом |
valid_ip | Возвращает FALSE если IP-адрес не является действительным |
matches | Возвращает FALSE если элемент не соответствует значению другого элемента field |
alpha | Возвращает FALSE если элемент содержит не только буквы |
valid_captcha | Возвращает FALSE если значение в сессии field не равно значению поля формы |
valid_date | Возвращает FALSE если элемент содержит не корректную дату |
Большинство этих правил используют фильтры , которые стали доступны в PHP 5.
Речь пойдет о валидации POST или GET данных, хотя принципе это можно отнести и к данным полученным другими способами, например куки. По мере разработки какого либо веб приложения требуется писать интерфейс взаимодействия с пользователями и естественно создавать различные формы для отправки пользователями данных на сервер. например это могут быть комментарии. Думаю всем понятно и очевидно, что пришедшие данные нужно проверять, соответствуют ли они типу, размеру, заданному диапазону. В первую очередь это требуется для безопасности системы, сайта или базы данных, т.к. неправильно переданные данные или умышленно не правильно сформированный запрос может открыть доступ для злоумышленника.
Во вторых непроверенные данные, будучи неправильными могут вызвать нестабильную работу скрипта, системы или всего сервера. Поэтому все данные нужно проверять и перепроверять, возможно кто-то скажет, что излишняя паранойя ни к чему, я же считаю, что в этом вопросе её излишней просто не может быть.
Не доверяйте данным пришедшим от пользователей, не под каким предлогом, не при каких обстоятельствах. Бывает такое, что лишний раз написать код проверяющий пришедшие данные просто лень или же мы надеяться, что существующих методов проверки достаточно, в результате чего делаем сами себе поблажки.
Немного отступления от темы:
Работа над проектами, разработка и программирование сайтов, скриптов, прочих систем занимает практически всё мое свободное время (по мимо рабочего), иными словами я занимаюсь этим делом максимально возможное количество часов в сутки. Время от времени возникает потребность в тестировании чего либо, ради забавы или просто любопытства. В итоге подобными тестируемыми лабораторными крысами становятся сайты сделанные на скорую руку, на самописных движках или на CMS древних версий. разумеется всё перечисленное страдает от криво написанного кода, нехватки котроля за данными и просто кишит различными багами. Собственно, в большинстве случаем за час моих экспериментов над такими сайтами мне удается найти несколько серьезных уязвимостей и большинство из них кроется в недостаточной валидации пришедших данных. В последнее время часто это встречается в скриптах обрабатывающих POST данные пришедших от JavaScript + Ajax.
Видимо программисты писавшие эти скрипты с использованием Ajax, считают, что раз все запросы происходят фоново, без ведома пользователя или просто без перезагрузки страницы, то и данные можно особо сильно не проверять.
как правило не малая часть таких скриптов оказывается на столько дырявой, что без особых усилий удается пробить брешь большего размера и залить свой шелл. разумеется исключительно с целью эксперимента и не более того (администрация таких сайтов всегда ставится в известность о имеющихся уязвимостях).
Думаю важность валидации всем понятна. На протяжении длительно времени я писал каждый раз один и тот же кусок кода, затем использовал собственные функции проверки данных, многие из которых были весьма примитивны и как правило разбросаны в разных частях (прииклюденных) файлов. В скором я начал знакомится с PHP фреймворками Zend, CI, Kohana, в каждом из был реализован свой класс для валидации данных, которые я заимствовал для своих проектов. В конце концов я решил заточить один из классов CI под свои нужды, но оказалось, что об этом уже позаботился автор одного из блогов по программированию. Далее делюсь его трудами, а именно модифицированной библиотекой CodeIgniter.
Разберем следующий код :
Просмотр кода PHP
require_once "validator.class.php" ; $validator = new Validator() ; $validator -> set_rules ("name" , "Ваше имя" , array ("required" => , "alpha" => ) ) ; $validator -> set_rules ("email" , "Ваш email" , array ("required" => "Поле %s обязательно для заполнения" , "valid_email" => ) ) ; if ($validator -> run () ) { echo "Валидация прошла успешно" ; } else { echo $validator -> get_string_errors () ; } |
Как видно из примера, первой строкой мы подключаем файл класса validator.calss.php
к нашем скрипту. Далее создаем экземпляр класса и сохраняем объект в переменную $validator
.
Затем используя метод $validator->set_rules($field, $label, $rules)
задаем поля для валидации.
Данный метод принимает 3 параметра:
После того, как все поля для валидации установлены, запускаем валидатор используя метод $validator->run() . Если валидация прошла успешно, то данный метод вернет значение TRUE , иначе, если есть хоть какие-то ошибки, вернет FALSE .
Для того чтобы получить сообщения об ошибках существует три метода:
По умолчанию сообщения об ошибках оборачиваются в тег . Для того чтобы задать свое оформление используйте метод set_error_delimiters($prefix, $suffix) . Например так:
Теперь сообщения об ошибках будут оборачиваться в div с классом «error»
Как видите все очень просто.
Просмотр кода PHP
$validator -> set_error_delimiters (" " , " " ) ; |
Для установки правил валидации Вы можете методу set_rules($fields) передать многомерный ассоциативный массив. Давайте посмотрим на пример:
Просмотр кода PHP
$rules = array ( array ( "field" => "name" , "label" => "Ваше имя" , "rules" => array ( "required" => "Поле %s обязательно для заполнения" , "alpha" => "Поле %s должно содержать только буквы" ) ) , array ( "field" => "email" , "label" => "Ваш email" , "rules" => array ( "required" => "Поле %s обязательно для заполнения" , "valid_email" => "Поле %s должно содержать правильный email-адрес" ) ) ) ; $validator -> set_rules ($rules ) ; |
Как видите я записал те же самые правила валидации, что и в первом примере, только в виде многомерного ассоциативного массива. Вы можете использовать любой из способов, который Вам больше подходит в той или иной ситуации.
Итак, какие же правила валидации поддерживает данный класс?
Я вынес в этот класс наиболее распространенные правила валидации, с которыми сталкивается каждый. Вот полный список этих правил:
required | Возвращает FALSE если поле не заполнено |
integer | Возвращает FALSE если значение не является целым числом |
float | Возвращает FALSE если значение не числового вида |
valid_url | Возвращает FALSE если значения не является корректным URL адресом |
valid_email | Возвращает FALSE если значения не является корректным e-mail адресом |
valid_ip | Возвращает FALSE если IP-адрес не является действительным |
matches | Возвращает FALSE если элемент не соответствует значению другого элемента field |
alpha | Возвращает FALSE если элемент содержит не только буквы |
valid_captcha | Возвращает FALSE если значение в сессии field не равно значению поля формы |
valid_date | Возвращает FALSE если элемент содержит не корректную дату |
Большинство этих правил используют фильтры , которые стали доступны в PHP 5.
При желании вы всегда можете расширить набор правил для валидации, дописав нужные функции в класс Validator.
Для того чтобы получить обработанное значение POST данных используется метод:
Просмотр кода PHP
Обычно данный метод вызываетя для очистки формы, при успешной обработке формы.
It is very essential to have the input to your form validated before taking the form submission data for further processing. When there are many fields in the form, the PHP validation script becomes too complex. Moreover, since you are doing the same or similar validation for most of the forms that you make, just too much of duplicate effort is spent on form validations.
This generic PHP form validator script makes it very easy to add validations to your form.
We create and associate a set of “validation descriptors” with each element in the form. The “validation descriptor” is a string specifying the type of validation to be performed. For example, “req” means required, “alpha” means allow only alphabetic characters and so on.
Each field in the form can have zero, one or more validations. For example, the input should not be empty, should be less than 25 chars, should be alpha-numeric, etc
You can associate a set of validation descriptors for each input field in the form.
Download the PHP form validation scriptYou can download the PHP form validation script below:
The zip file contains the form validation script formvalidator.php, documentation and usage samples.
The first argument is the name of the input field in the form. The second argument is the validation descriptor that tells the type of the validation required. The third argument is the error message to be displayed if the validation fails.
$inpname: $inp_err
\n"; } } ExampleThe example below will make the idea clearer
Name: Email:
Adding Custom ValidationIf you want to add a custom validation, which is not provided by the validation descriptors, you can do so. Here are the steps:
class MyValidator extends CustomValidator { function DoValidate(&$formars,&$error_hash) { if(stristr($formars["Comments"],"http://")) { $error_hash["Comments"]="No URLs allowed in comments"; return false; } return true; } }
$validator = new FormValidator(); $validator->addValidation("Name","req","Please fill in Name"); $validator->addValidation("Email","email", "The input for Email should be a valid email value"); $validator->addValidation("Email","req","Please fill in Email"); $custom_validator = new MyValidator(); $validator->AddCustomValidator($custom_validator);
The custom validation function will be called automatically after other validations.
Table of Validation DescriptorsHere is the list of all validation descriptors:
Validation Descriptor | Usage |
req | The field should not be empty |
maxlen=??? | checks the length entered data to the maximum. For example, if the maximum size permitted is 25, give the validation descriptor as “maxlen=25” |
minlen=??? | checks the length of the entered string to the required minimum. example “minlen=5” |
alnum | Check the data if it contains any other characters other than alphabetic or numeric characters |
alnum_s | Allows only alphabetic, numeric and space characters |
num | Check numeric data |
alpha | Check alphabetic data. |
alpha_s | Check alphabetic data and allow spaces. |
The field is an email field and verify the validity of the data. | |
lt=??? lessthan=??? | Verify the data to be less than the value passed. Valid only for numeric fields. example: if the value should be less than 1000 give validation description as “lt=1000” |
gt=??? greaterthan=??? | Verify the data to be greater than the value passed. Valid only for numeric fields. example: if the value should be greater than 10 give validation description as “gt=10” |
regexp=??? | Check with a regular expression the value should match the regular expression. example: “regexp=^{1,20}$” allow up to 20 alphabetic characters. |
dontselect=?? | This validation descriptor is for select input items (lists) Normally, the select list boxes will have one item saying ‘Select One’. The user should select an option other than this option. If the value of this option is ‘Select One’, the validation description should be “dontselect=Select One” |
dontselectchk | This validation descriptor is for check boxes. The user should not select the given check box. Provide the value
of the check box instead of ?? For example, dontselectchk=on |
shouldselchk | This validation descriptor is for check boxes. The user should select the given check box. Provide the value of the check box instead of ?? For example, shouldselchk=on |
dontselectradio | This validation descriptor is for radio buttons. The user should not select the given radio button. Provide the value of the radio button instead of ?? For example, dontselectradio=NO |
selectradio | This validation descriptor is for radio buttons. The user should select the given radio button. Provide the value of the radio button instead of ?? For example, selectradio=yes |
selmin=?? | Select atleast n number of check boxes from a check box group. For example: selmin=3 |
selone | Makes a radio group mandatory. The user should select atleast one item from the radio group. |
eqelmnt=??? | compare two elements in the form and make sure the values are the same For example, ‘password’ and ‘confirm password’. Replace the ??? with the name of the other input element. For example: eqelmnt=confirm_pwd |
Почти всем интерактивные веб-приложения необходимо проверить вводимые данные. Например, в регистрационной форме, вероятно, потребует пароль для подтверждения. Может быть, адрес электронной почты должен быть уникальным. Проверка данных может быть громоздким процессом. К счастью,только не в Laravel.Класс Validator обеспечивает удивительный набор помощников для проверки, максимально облегчая проверку данных. Давайте рассмотрим пример:
Получение массива данных для валидации: $input = Input::all(); Определение правил валидации данных: $rules = array("name" => "required|max:50", "email" => "required|email|unique:users",); Создание экземпляра Validator и валидация данных: $validation = Validator::make($input, $rules); if ($validation->fails()) { return $validation->errors; }При наличии свойства errors вы получаете доступ к сборщику сообщений, позволяющему легко создавать свои сообщения об ошибках. Конечно же, все правила валидации имеют соощения об ошибках по умолчанию. Стандартные сообщения об ошибках находятся в language/en/validation.php .
Теперь вы знакомы с основными правилами использования класса Validator. Вы готовы к исследованию и изучению правил используемых для проверки ваших данных!
Правила валидации Обязательные данные Проверка на обязательное не пустое значение параметра: "name" => "required" Alpha, Alpha Numeric, & Alpha Dash Проверка на наличие только букв: "name" => "alpha" Проверка на наличие только букв и цифр: "username" => "alpha_num" Проверка на наличие только букв, цифр, тире и символа подчеркивания: "username" => "alpha_dash" Размер Проверка на размер строки строчного атрибута, или диапазон значений числового атрибута: "name" => "size:10" Проверка на диапазон значений: "payment" => "between:10,50"Примечание: Минимум и максимум включены в диапазон.
Проверка минимального размера атрибута: "payment" => "min:10" Проверка максимального размера атрибута: "payment" => "max:50" Числовые типы Проверка принадлежности атрибута к числовому типу: "payment" => "numeric" Проверка принадлежности атрибута к целочисленному типу: "payment" => "integer" Вхождения и исключения Проверка атрибута на вхождение в массив значений: "size" => "in:small,medium,large" Проверка атрибута на исключение из массива значений: "language" => "not_in:cobol,assembler" ПодтверждениеПравило confirmed проверяет, что для данного атрибута есть соответствующее подтверждение * attribute_confirmation *.
Проверка атрибута на подтверждение: "password" => "confirmed"В этом примере Validator проверяет, что параметр password удовлетворяет условиям password_confirmation из массива валидации.
АкцептированиеПравило accepted проверяет параметр на значение yes или 1 . Это правило проверяет установку обязательных чекбоксов, таких, как, например, флажок согласия с "Условиями предоставления услуг".
Проверка акцептирования: "terms" => "accepted" Соответствия и различия Проверка, что атрибут такой же как, и сравниваемый другой артибут: "token1" => "same:token2" Проверка на то, что атрибут имеет разное значение: "password" => "different:old_password", Регулярные выраженияПравило match проверяет атрибут на удовлетворение регулярному выражению.
Поверка на удовлетворение регулярному выражению: "username" => "match:/+/"; Уникальность и существование Проверка параметра на уникальность в базе данных: "email" => "unique:users"В этом примере параметр email проверяется на уникальность в таблице users . Необходимо проверить уникальность атрибута другого столбца, кроме этого? Нет проблем:
Указание другого столбца для проверки: "email" => "unique:users,email_address"Часто, при обновлении записи, вам нужно использовать правило уникальности, но при этом исключить обновляемую запись. Напрмер, вы хотите дать возможность пользователям изменять свои почтовые адреса. Но, когда запускается правило unique , вам нужно пропустить этого пользователя, чтобы не вызвать мнимую ошибку проверки. Это просто:
Игнорирование указанного ID: "email" => "unique:users,email_address,10" Проверка на наличие атрибута в указанной базе данных: "state" => "exists:states" Указание имени столбца для правила exists: "state" => "exists:states,abbreviation" Даты Проверка того, что параметр даты имеет значение до...: "birthdate" => "before:1986-28-05"; Проверка того, что параметр даты имеет значение после...: "birthdate" => "after:1986-28-05";Примечание: Проверка before и after использует функцию PHP strtotime .
E-Mail адреса Проверка того, что параметр является E-Mail адресом: "address" => "email"Примечание: Это правило использует встроенный в PHP метод filter_var .
URLs Проверка того, что параметр есть URL: "link" => "url" Проверка того, что параметр есть активный URL: "link" => "active_url"Примечание: Правило active_url используетs checkdnsr для проверки активности URL.
ЗагрузкиПравила mimes проверяют, что загружаемый файл соответствует MIME типу. Это правило использует расширение PHP Fileinfo проверяющее содержимое файла и определяющее его тип. Любые расширения файлов, применимые к этому правилу, определяются в config/mimes.php .
Проверка принадлежности файла определенному типу: "picture" => "mimes:jpg,gif"Примечание: При проверке не забудьте использовать Input::file() или Input::all().
Проверка того, что файл изображение: "picture" => "image" Проверка на размер файла: "picture" => "image|max:100" Запрос сообщения об ошибкеLaravel позволяет работать с сообщениями об ошибках с помощью простого класса - сборщика ошибок. После вызова методов passes или fails экземпляра Validator, вы можете получить доступ к ошибке при помощи свойства errors . Сборщик ошибок имеет простые функции для запроса сообщений об ошибках:
Определение, что атрибут имеет сообщение об ошибке: if ($validation->errors->has("email")) { // The e-mail attribute has errors... } Запрос первого сообщения об ошибке для атрибута: echo $validation->errors->first("email");Вам может понадобиться обернуть ваше сообщение об ошибке в HTML тэги. Нет проблем. Вызывая:message place-holder, определите формат вторым параметром метода.
Форматирование сообщения об ошибке: echo $validation->errors->first("email", ""); Получение всех сообщений об ошибках для атрибута: $messages = $validation->errors->get("email"); Форматирование всех сообщений об ошибках для аттрибута: $messages = $validation->errors->get("email", ""); Получение всех сообщений об ошибках для всех атрибутов: $messages = $validation->errors->all(); Форматирование всех сообщений об ошибках для всех атрибутов: $messages = $validation->errors->all(""); Прохождение валидацииПосле того как вы выполнили вашу проверку, нужен простой способ отображения ошибок в представлении. Laravel делает его очень легко. Давайте рассмотрим типичный сценарий. Это может быть определено двумя путями:
Route::get("register", function() { return View::make("user.register"); }); Route::post("register", function() { $rules = array(...); $validation = Validator::make(Input::all(), $rules); if ($validation->fails()) { return Redirect::to("register")->with_errors($validation); } });
Отлично! Итак, мы имеем два простых маршрута для формы регистрации. Один для обработки отображения формы, и один для обработки ввода в форму. В POST маршруте мы проводим некоторые проверки на входе. Если проверка не пройдена, будем преадресовывать обратно в регистрационную форму с указанием ошибок и отображения последних в форме.
Но, обратите внимание, мы явно не связываем ошибки с целью в нашем GET маршруте . Тем не менее, переменная ошибки будет доступна в представлении. Laravel разумно определяет, есть ли ошибки в работе сессии, и если они есть, присоединяет сообщения к представлению. Если ошибок нет, пустой контейнер сообщения об ошибке все равно будет присоединен к представлению. В представлении всегда будет доступен контейнер сообщений об ошибках. Нам нравится облегчать вам жизнь.
Пользовательские сообщения об ошибкахХотите использовать собственное сообщение об ошибке? Может быть, вы даже хотите использовать пользовательские сообщения об ошибке для данного атрибута и правила. В любом случае, класс Validator позволяет легко это сделать.
Создание массива собственных сообщений об ошибках для Validator: $messages = array("required" => "The:attribute field is required.",); $validation = Validator::make(Input::get(), $rules, $messages);Отлично! Теперь наши пользовательских сообщения будет использоваться всегда при проверке. Но, что за выражение :attribute в нашем сообщении. Для облегчения вашей жизни, класс Validator заменяет :attribute на атрибут, ввод которго вызвал ошибку. Он даже удалит символ подчеркивания из имени атрибута. Вы также можете использовать :other , :size , :min , :max , и :values заполнители для конструирования ваших сообщений об ошибках.
Примеры пользовательских сообщений об ошибках: $messages = array("same" => "The:attribute and:other must match.", "size" => "The:attribute must be exactly:size.", "between" => "The:attribute must be between:min - :max.", "in" => "The:attribute must be one of the following types: :values",);Что, если вам нужно определить необходимое сообщение, но только для атрибута электронной почты? Без проблем. Просто укажите сообщение, используя attribute_rule именование:
Определение сообщения для конктретного атрибута: $messages = array("email_required" => "We need to know your e-mail address!",);В данном примере, пользовательское сообщение об ошибке будет использовано только для атрибута email, в остальных случаях будут использоваться стандартные сообщения.
В то же время, если вы используете много собственных сообщений об ошибках, указание всех их в коде может сделать его громоздким и неудобным. По этой причине есть возможность определить собственный массив в языковом файле:
Добавление собственного массива в языковый файл: "custom" => array("email_required" => "We need to know your e-mail address!",) Собственные правила валидацииLaravel предоставляет ряд мощных правил проверки. Тем не менее, вы можете создать свои собственные. Есть два простых способа создания правил проверки. И тот и другой надежны в использовании. Вам остается только выбрать более подходящий для вашего проекта.
Регистрация собственного валидационного правила: Validator::register("awesome", function($attribute, $value, $parameters) { return $value == "awesome"; });В этом примере мы зарегистрировали новые правила проверки для класса Validator. Это правило получает три параметра. Во-первых, это имя проверяемого атрибута, второй - значение проверяемого атрибута, а третий представляет собой массив из параметров, которые были заданы для правила.
Так выглядит вызов вашего правила:
$rules = array("username" => "required|awesome",);
Конечно, вам нужно определить сообщение об ошибке для нового правила. Вы можете сделать это либо в специальных сообщениях массива:
$messages = array("awesome" => "The attribute value must be awesome!",); $validator = Validator::make(Input::get(), $rules, $messages);
или, добавив запись для правила в language/en/validation.php :
"awesome" => "The attribute value must be awesome!",
Как уже упоминалось выше, вы даже можете указать и получить список параметров в пользовательском правиле:
// При построении правила... $rules = array("username" => "required|awesome:yes",); // В правиле... Validator::register("awesome", function($attribute, $value, $parameters) { return $value == $parameters; }
В данном примере параметр аргументов вашего правила проверки будет получать массив, содержащий один элемент: "да".
Еще один способ для создания и хранения пользовательских правил проверки заключается в расширении класса Validator. Причем благодаря пространствам имен в Laravel этот класс может расширить сам себя. Тем самым вы создаете новую версию валидатора, который имеет все ранее существующие функции в сочетании с новыми дополнениями. Вы даже можете выбрать, чем заменить некоторые из методов по умолчанию, если вы хотите. Давайте посмотрим на примере:
Сначала, создаете класс Validator который наследует класс Laravel\Validator и размещаете его в application/libraries :
Определение собственного класса:Run example »
Notice that at the start of the script, we check whether the form has been submitted using $_SERVER["REQUEST_METHOD"]. If the REQUEST_METHOD is POST, then the form has been submitted - and it should be validated. If it has not been submitted, skip the validation and display a blank form.
However, in the example above, all input fields are optional. The script works fine even if the user does not enter any data.
The next step is to make input fields required and create error messages if needed.