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.
You 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"; } }The example below will make the idea clearer
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"); if($validator->ValidateForm()) { echo "
$inpname: $inp_err
\n"; } } } if(true == $show_form) { ?>If 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.
Here 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 |
Validation of data is a fundamentally important aspect of a CRUD application. You need to be sure that the data that the client is sending you is what you expect. This is not just for security reasons, protecting your data from misuse and intentional corruption, but also simply from unintentional mistakes in submitting data. Strings limited to a certain length, dates in a particular format and required fields are all common uses of data validation.
The Editor PHP libraries provide two different validation methods:
Please note that PHP validation in Editor 1.6 and older was a little different. The older form of validation will still work with the 1.7+ libraries and its documentation remains available , but for new projects use the validation style discussed here.
Field validation is the one you will most commonly work with - for example checking that an e-mail address field actually contains an e-mail address, and Editor provides a number of ready to use validators for the most common data types as well as the ability to specify your own. Global validation can be useful when checking dependencies between fields and conflicts in the existing data set.
The Editor PHP libraries provide a validator() method for the Field class and a number of pre-built validation methods in the Validate class. Each of these validation methods returns a function which is executed when required to validate submitted data.
Consider the following example - the Validate::minNum() function is configured with a number and returns a function that can be used for the field validator.
Field::inst("age") ->validator(Validate::minNum(16));
Please see below for more detailed examples.
Each validation method provided by the Validation class can optionally accept parameters to tell it how to validate data (for example the minLen method will accept an integer to indicate the minimum length of an acceptable string), but all optionally accept a ValidateOptions class instance. This class defines a number of options that are shared between all validation methods.
The ValidateOptions class is constructed with ValidateOptions::inst() (or new ValidateOptions() in PHP 5.4+) similar to the other Editor classes. It has three methods that can be used to alter the validation behaviour:
It can often be useful to use multiple validators together, for example to confirm that an input string is less than a certain number of characters and also that it is unique in the database. Multiple validators can be added to a field simply by calling the Field->validator() method multiple times. Rather than overwriting the previous validator it will in fact add them together. They are run in the sequence they were added, and all validators must pass for the data to be accepted as valid.
As an example consider the following code which will check the min and max length of the data, and also that it is unique:
Field::inst("stock_name") ->validator(Validate::minLen(10)) ->validator(Validate::maxLen(12)) ->validator(Validate::unique());
The Validate class in the Editor PHP libraries has a number of methods which can be used to perform validation very quickly and easily. These are:
Note that these methods are for use with the Mjoin->validator() method (Editor 1.9 and newer). Please see the Mjoin documentation for more details.
If the provided methods above don"t suit the kind of validation you are looking for, it is absolutely possible to provide custom validation methods. The validator() Field method will accept a function that returns either true or a string and accepts the following input parameters:
The return value should be true to indicate that the validate passed, or a string that contains an error message if the validation failed.
The following simple example shows how a maxLen string check could be implemented with a custom validation method:
Field::inst("last_name") ->validator(function ($val, $data, $field, $host) { return strlen($val) > 50 ? "Name length must be 50 characters or less" : true; });
Use the Validation.minNum() method to validate an input as numeric and greater or equal to a given number (no validation options specified, so the defaults are used):
// Simple non-empty field Field::inst("age") ->validator(Validate::minNum(16))
As above, but with ValidateOptions used to set the error message:
// Number range check with custom error message Field::inst("range") ->validator(Validate::minNum(16, ValidateOptions::inst() ->message("Minimum age is 16")));
This time validating an e-mail address which cannot be empty and must be submitted:
Field::inst("email") ->validator(Validate::email(ValidateOptions::inst() ->allowEmpty(false) ->optional(false)));
A join with dbValues which will accept an empty value, which is stored as null on the database:
Field::inst("users.site") ->options(Options::inst() ->table("sites") ->value("id") ->label("name")) ->validator(Validate::dbValues()),
Allow only certain values to be submitted:
Field::inst("group") ->validator(Validate::values(array("CSM", "FTA", "KFVC")))
The following shows a complete Editor example with validation methods applied:
Ditor::inst($db, "staff") ->fields(Field::inst("first_name") ->validator(Validate::notEmpty(ValidateOptions::inst() ->message("A first name is required"))), Field::inst("last_name") ->validator(Validate::notEmpty(ValidateOptions::inst() ->message("A last name is required"))), Field::inst("position"), Field::inst("email") ->validator(Validate::email(ValidateOptions::inst() ->message("Please enter an e-mail address"))), Field::inst("office"), Field::inst("extn"), Field::inst("age") ->validator(Validate::numeric()) ->setFormatter(Format::ifEmpty(null)), Field::inst("salary") ->validator(Validate::numeric()) ->setFormatter(Format::ifEmpty(null)), Field::inst("start_date") ->validator(Validate::dateFormat("Y-m-d")) ->getFormatter(Format::dateSqlToFormat("Y-m-d")) ->setFormatter(Format::dateFormatToSql("Y-m-d"))) ->process($_POST) ->json();
You may also find it useful to be able to define a global validator that will execute whenever a request is made to the server and the Editor->process() method is executed. This method can be used to provide security access restrictions, validate input data as a whole or even to check that a user is logged in before processing the request.
The function that is given to the Editor->validator() method has the following signature:
The return value from the function should be a string if the validation fails, where the string returned is the error message to show the end user. If the validation passes, return an empty string, null or simply have no return statement.
Note that this function is executed only once when the Editor->process() method is called, rather than once per submitted row. Also, as of Editor 1.9, it is possible to add multiple validation functions by calling Editor->validator() multiple times, just as with the field validators. The given validators will run sequentially.
The PHP API developer documentation for the Editor PHP classes is available for detailed and technical discussion about the methods and classes discussed above.
Почти всем интерактивные веб-приложения необходимо проверить вводимые данные. Например, в регистрационной форме, вероятно, потребует пароль для подтверждения. Может быть, адрес электронной почты должен быть уникальным. Проверка данных может быть громоздким процессом. К счастью,только не в Laravel.Класс Validator обеспечивает удивительный набор помощников для проверки, максимально облегчая проверку данных. Давайте рассмотрим пример:
При наличии свойства errors вы получаете доступ к сборщику сообщений, позволяющему легко создавать свои сообщения об ошибках. Конечно же, все правила валидации имеют соощения об ошибках по умолчанию. Стандартные сообщения об ошибках находятся в language/en/validation.php .
Теперь вы знакомы с основными правилами использования класса Validator. Вы готовы к исследованию и изучению правил используемых для проверки ваших данных!
Примечание: Минимум и максимум включены в диапазон.
Правило confirmed проверяет, что для данного атрибута есть соответствующее подтверждение * attribute_confirmation *.
В этом примере Validator проверяет, что параметр password удовлетворяет условиям password_confirmation из массива валидации.
Правило accepted проверяет параметр на значение yes или 1 . Это правило проверяет установку обязательных чекбоксов, таких, как, например, флажок согласия с "Условиями предоставления услуг".
Правило match проверяет атрибут на удовлетворение регулярному выражению.
В этом примере параметр email проверяется на уникальность в таблице users . Необходимо проверить уникальность атрибута другого столбца, кроме этого? Нет проблем:
Часто, при обновлении записи, вам нужно использовать правило уникальности, но при этом исключить обновляемую запись. Напрмер, вы хотите дать возможность пользователям изменять свои почтовые адреса. Но, когда запускается правило unique , вам нужно пропустить этого пользователя, чтобы не вызвать мнимую ошибку проверки. Это просто:
Примечание: Проверка before и after использует функцию PHP strtotime .
Примечание: Это правило использует встроенный в PHP метод filter_var .
Примечание: Правило active_url используетs checkdnsr для проверки активности URL.
Правила mimes проверяют, что загружаемый файл соответствует MIME типу. Это правило использует расширение PHP Fileinfo проверяющее содержимое файла и определяющее его тип. Любые расширения файлов, применимые к этому правилу, определяются в config/mimes.php .
Примечание: При проверке не забудьте использовать Input::file() или Input::all().
Laravel позволяет работать с сообщениями об ошибках с помощью простого класса - сборщика ошибок. После вызова методов passes или fails экземпляра Validator, вы можете получить доступ к ошибке при помощи свойства errors . Сборщик ошибок имеет простые функции для запроса сообщений об ошибках:
Вам может понадобиться обернуть ваше сообщение об ошибке в HTML тэги. Нет проблем. Вызывая:message place-holder, определите формат вторым параметром метода.
После того как вы выполнили вашу проверку, нужен простой способ отображения ошибок в представлении. 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 позволяет легко это сделать.
Отлично! Теперь наши пользовательских сообщения будет использоваться всегда при проверке. Но, что за выражение :attribute в нашем сообщении. Для облегчения вашей жизни, класс Validator заменяет :attribute на атрибут, ввод которго вызвал ошибку. Он даже удалит символ подчеркивания из имени атрибута. Вы также можете использовать :other , :size , :min , :max , и :values заполнители для конструирования ваших сообщений об ошибках.
Что, если вам нужно определить необходимое сообщение, но только для атрибута электронной почты? Без проблем. Просто укажите сообщение, используя attribute_rule именование:
В данном примере, пользовательское сообщение об ошибке будет использовано только для атрибута email, в остальных случаях будут использоваться стандартные сообщения.
В то же время, если вы используете много собственных сообщений об ошибках, указание всех их в коде может сделать его громоздким и неудобным. По этой причине есть возможность определить собственный массив в языковом файле:
Laravel предоставляет ряд мощных правил проверки. Тем не менее, вы можете создать свои собственные. Есть два простых способа создания правил проверки. И тот и другой надежны в использовании. Вам остается только выбрать более подходящий для вашего проекта.
В этом примере мы зарегистрировали новые правила проверки для класса 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 :
Имейте в виду, что вам еще нужно создать специальное сообщение для правил проверки, которые вы создаете. Метод для этого так же независим от того, как вы определяете правила!
методом POST. И первой задачей разработчика является валидация пользовательских данных пришедших методом POST. Как правило эта валидация сводится :Как правило все эти проверки повторяются и Вам приходится писать практически один и тот же код, для валидации 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.
При создании веб-приложений важно серьезно относиться к безопасности, особенно, когда приходится иметь дело с получением данных от пользователей.
Общее правило безопасности - не доверять никому, так что нельзя надеяться на то, что пользователи всегда будут вводить в формы правильные значения. Например, вместо ввода в поле правильного email-адреса, пользователь может ввести неверный адрес, или вообще какие-нибудь вредоносные данные.
Когда дело доходит до валидации пользовательских данных, ее можно проводить как на стороне клиента (в веб-браузере), так и на серверной стороне.
Ранее валидацию на стороне клиента можно было провести только с помощью JavaScript. Но все изменилось (или почти изменилось), так как с помощью HTML5 валидацию можно проводить средствами браузера, без необходимости писать сложные скрипты для валидации на JavaScript.
HTML5 предоставляет довольно надежный механизм, основанный на следующих атрибутах тега : type , pattern и require . Благодаря этим новым атрибутам вы можете переложить некоторые функции проверки данных на плечи браузера.
Давайте рассмотрим эти атрибуты, чтобы понять, как они могут помочь в валидации форм.
Этот атрибут говорит, какое поле ввода отобразить для обработки данных, например, уже знакомое поле типа
Некоторые поля ввода уже предоставляют стандартные способы валидации, без необходимости писать дополнительный код. Например, проверяет поле на то, что введенное значение соответствует шаблону правильного email адреса. Если в поле введен неверный символ, форму нельзя будет отправить, пока значение не будет исправлено.
Попробуйте поиграться со значениями поля email в нижеприведенной демонстрации .
Также существуют другие стандартные типы полей, вроде , и для валидации чисел, URL’ов и телефонных номеров соотвествено.
Замечание: формат телефонного номера различается для разных стран из-за несоответствия количества цифр в телефонных номерах и разности форматов. Как результат, спецификация не определяет алгоритм проверки телефонных номеров, так что на время написания статьи данная возможность слабо поддерживается браузерами.
К счастью для нас, валидацию телефонных номеров можно провести с использованием атрибута pattern , который принимает как аргумент регулярное выражение, который мы рассмотрим далее.
Атрибут pattern , скорее всего, заставит многих фронтенд-разработчиков прыгать от радости. Этот атрибут принимает регулярное выражение (аналогичное формату регулярных выражений JavaScript), по которому будет проверяться корректность введенных в поле данных.
Регулярные выражения это язык, использующийся для разбора и манипуляции текстом. Они часто используются для сложных операций поиска и замены, а также для проверки корректности введенных данных.
На сегодняшний день регулярные выражения включены в большинство популярных языков программирования, а также во многие скриптовые языки, редакторы, приложения, базы данных, и утилиты командной строки.
Регулярные выражения (RegEX) являются мощным, кратким и гибким инструментом для сопоставления строки текста, вроде отдельных символов, слов или шаблонов символов.
Передав регулярное выражение в качестве значения атрибута pattern можно указать, какие значения приемлемы для данного поля ввода, а также проинформировав пользователя об ошибках.
Давайте посмотрим на пару примеров использования регулярных выражений для валидации значения полей ввода.
Как упоминалось ранее, тип поля tel не полностью поддерживается браузерами из-за несоответствия форматов номеров телефонов в разных странах.
Например, в некоторых странах формат телефонных номеров представляется в виде xxxx-xxx-xxxx , и сам телефонный номер будет что-то вроде этого: 0803-555-8205 .
Регулярное выражение, которому соответствует данный шаблон, такое: ^\d{4}-\d{3}-\d{4}$ . В коде это можно записатьтак :
Это атрибут булевого типа, использующийся для указания того, что значение данного поле обязательно заполнить для того, чтобы отправить форму. При добавлении этого атрибута полю браузер потребует от пользователя заполнить данное поле перед отправкой формы.
Это избавляет нас от реализации проверки полей с помощью JavaScript, что может сохранить немного времени разработчикам.
Например: или (для совместимости с XHTML)
Во всех демках, которые вы видели выше, используют атрибут required , так что вы можете попробовать его в действии, попытавшись отослать форму без заполнения полей.
Поддержка валидации форм браузерами довольно хороша , а для старых браузеров вы можете использовать полифиллы.
Стоит отметить, что надеяться на валидацию только на стороне браузера опасно, так как эти проверки могут быть легко обойдены злоумышленниками или ботами.
Не все браузеры поддерживают HTML5, и не все данные, посланные вашему скрипту, придут с вашей формы. Это значит, что перед тем, как окончательно принять данные от пользователя, необходимо проверить их корректность на стороне сервера.
