Codeigniter vs Kohana ||

VS

Codeigniter vs Kohana ||

Раунд 2. Проверка форм

Вторая часть фреймворка, которая на мой взгляд, является очень важной — это средства и возможности проверки корректности данных, введенных пользователем или иными словами — валидация форм.

Оба фреймворка имееют достаточно развитые возможности проверки данных, о них я сегодня и постараюсь рассказать.

Начнем с Codeigniter.

Совсем недавно вышла версия 1.7 данного фреймворка, класс для проверки данных, претерпел существенные изменения, поэтому все описанное ниже относится только к последней версии CI.

И так… для того что бы библиотека валидации форм была доступна в Ваших контроллерах (как правило именно там и происходит валидация) необходимо выполнить следующее:

$this->load->library('form_validation');
  1. - стандартная процедура загрузки библиотеки для CI. После этого все действия можно выполнять, обращаясь к
  2. <pre lang="PHP">$this->form_validation->some_method();

Kohana
Kohana предлагает несколько вариантов:

$validator = new Validation($_POST);
  1.  
  2. $array = array_merge($_POST,$_GET); // объединем $_GET и $_POST для проверки
  3.  
  4. $validator = new Validation($array);
  5.  
  6. $validator = Validation::factory($_POST) // вызов статичного метода

После того как библиотеки загружены, необходимо указать правила валидации полей - то, собственно ради чего все это и затевалось...

В CI для установки правил валидации используется метод set_rules()

$this->form_validation->set_rules($field,$name,$rules)
  1. $field - имя поля в массиве $_POST;
  2.  
  3. $name - псевдоним поля - это значение появится в сообщении об ошибке
  4.  
  5. $rules - правила валидации
  6.  
  7. Подробнее о правилах валидации...
  8.  
  9. Помимо собственно правил проверки, можно задать правила (или фильтры) для<strong> пред-обрабокти</strong> и/или <strong>пост-обработки</strong> данных.
  10.  
  11. Например, рассмотрим следующее правило:
  12.  
  13. <strong>"trim|required|strtolower"</strong>
  14.  
  15. Символ "|" используется для объединения правил - в терминах CI "каскадирование".   Итак...
  16. <ul>
  17.  <li> trim - стандартная функция php, которая удаляет все начальные и конечные пробелы</li>
  18.  <li> required - одно из встроенных правил CI, которое делает поле обязательным для заполнения</li>
  19.  <li> strtolower - стандартная функция php, которая переводит все символы в нижний регистр</li>
  20. </ul>
  21. Таким образом в этом правиле...
  22. <ul>
  23.  <li> trim – функция, которая вызовется перед проверкой поля (пред-обработка)</li>
  24.  <li> required - само правило валидации</li>
  25.  <li> strtolower - функция, которая вызовется после проверки поля (пост-обработка)</li>
  26. </ul>
  27. Последовательность действий, которые выполнит CI будет следующая:
  28. <ol>
  29.  <li>выполнится функция trim</li>
  30.  <li>выполнится проверка на заполнение поля (required)</li>
  31.  <li> строка трансформируется в нижний регистр и запишется в массив $_POST(свое исходное место)</li>
  32. </ol>
  33. Нужно отметить очень важный момент:
  34. <blockquote><span style="color: #ff6600;">Все функции пред- и пост-обработки  в CI изменяют глобальный массив $_POST, т.е. данные модифицируются непосредственно в источнике.</span></blockquote>
  35. В качестве правил обработки могут выступать любые PHP функции, принимающие один параметр.
  36.  
  37. Кроме того правила валидации для полей можно задавать через массив, собирая все правила в одном массиве, а так же, правила можно сохранять в конфигурационный файл, для последующего использования (подробнее об этом можно прочитать в документации CI).
  38.  
  39. В <strong>Kohana</strong> для установки правил валидации используется похожий метод:
  40. <strong>add_rules($field, $rule, $rule...,...,...)</strong>
  41.  
  42. $field – поле для проверки
  43. $rule – правило проверки
  44.  
  45. Пример:
  46. <pre lang="PHP">$validator = new Validation($_POST);
  47. $validator->add_rules(‘userEmail’,’required’,’email’)

Разберем этот пример.
Для поля «userEmail» (переданное методом POST) устанавливаются следующие правила:

  • поле обязательно для заполнения (required)
  • поле должно содержать корректный email адрес (email)

Kohana при валидации форм использует Valid helper (http://docs.kohanaphp.com/helpers/valid) поэтому все доступные правила валидации можно посмотреть в документации этого хелпера.

Синтаксис задания правила может быть одним из следующих:

$validator->add_rules(‘userEmail’,’required’,’email’) // стандартный способ
  1. $validator->add_rules(‘userEmail’,’required’,’valid::email) // явно указав правило
  2. $validator->add_rules(‘userEmail’,’required’,array(‘valid’,’email’)) // правило задается через массив

На мой взгляд, самыми удобными являются первые два варианта (хотя, как говорится, «на вкус и цвет...»).

Кроме валидации, Kohana как и CI предлагает возможности пред- и пост-обработки данных, однако для этого используется совершенно другой подход.

Для задания правил обработки используется методы:

pre_filter($function,$filed,$field)

post_filter($function,$filed,$field)

Метод pre_filter($function,$filed,$field....) – задает пред-обработку данных

$function – имя функции, которая выполняет обработку данных (как пример – «trim»)
$field – поле, которые необходимо обработать.

Если поля не указаны явно – обработка применятся ко всем входным данным.

Метод post_filter($function,$filed,$field) работает аналогичным образом, за исключением того, что обработка выполняется уже после валидации данных.

Таким образом в Kohana, в отличие от CI (где правила обработки задаются индивидуально для каждого поля), правила обработки, могут быть заданы «глобально» для всех входящих полей. Кроме того CI при выполнении функций обработки – изменяет непосредственно данные в источнике (например массив $_POST), Kohana же оставляет данные в источнике неизменными, а обработанные данные помещает в объект класса Validation.

В обоих фреймворках, кроме стандартных правил валидации (встроенных), можно создавать свои собственные. Рассмотрим эту возможность подробнее.
Собственное правило валидации это простая PHP функция, которая выполняет необходимые действия.

В CI для задания собственного правила необходимо

  • написать функцию, которая будет выполнять проверку
  • установить правило валидации для поля формы

Функция может выполнять абсолютно любые действия, соединяться с БД, читать из файла и т.д.

public function checkName($str){
  1.  
  2. ………..
  3.  
  4. ………..
  5.  
  6. ………..
  7.  
  8. }

Для установки собственно правила необходимо указать имя функции, предварив его префиксом «callback_»

$this->form_validation->set_rules('userName','имя','trim|strtolower|callback_checkName');
  1. <blockquote><span style="color: #ff6600;">Рекомендация. Так как функция проверки будет являться методом текущего контроллера, для того что-бы она не была доступна через URL сайта, необходимо сделать ее «приватной». Для CI (см статью 1). это означает, необходимость перед именем функции добавить префикс "_"</span></blockquote>
  2. <strong>Kohana</strong> использует похожий принцип, однако на мой взгляд, он менее очевиден.
  3. И так. Для задания собственного правила проверки необходимо:
  4. <ul>
  5.  <li> написать функцию, которая будет выполнять проверку</li>
  6.  <li> установить правило валидации для поля формы</li>
  7. </ul>
  8. Для установки собственного правила необходимо вызвать метод <strong>add_callbacks()</strong>
  9.  
  10. Пример:
  11. <pre lang="PHP">$validator->add_callbacks('userName',array($this,'checkName'));

userName – поле для проверки
$this - текущий объект класса валидации
checkName – функция проверки

Так же как и в случае с CI функцию проверки необходимо (рекомендуется) сделать приватной для контроллера, в Kohana это можно сделать двумя способами (см статью 1).

На мой взгляд, подход CI для задания собственных правил – более интуитивен и легок в использвании.

Для установки текста сообщения об ошибке, при использовании собственных функций (и не только) для проверки данных,в обоих фреймвоках используются практически одинаковые функции.

В CI необходимо вызвать метод set_message('rule', 'Error Message');

'rule' - правило для которого устанавливается текст сообщения

'Error message' - текст сообщения

Пример:

$this->validation->set_message('callback_checkName','Укажите корректное имя пользователя')
  1. - данный код  устанавливает текст сообщения об ошибке для пользовательской функции проверки "checkName". CI хранит сообщения об ошибках в языковом  файле, при необходимости тексты сообщений можно изменить.
  2.  
  3. В Kohana необходимо вызвать метод  <strong>add_error()</strong>:
  4. <pre lang="PHP">$validation->add_error($field,$errorMsg);

$field - проверяемое поле

$errorMsg - сообщение об ошибке

Так же как и CI, Kohana позволяет сохранять тексты сообщений об ошибках во внешних файлах.

Для запуска процесса валидации в CI используется метод run(), который при наличии ошибок - вернет FALSE:

$this->form_validation->run();
  1. В Kohana используется метод validate(), так же возвращает FALSE при неудачной валидации;
  2. <pre lang="PHP">$validator->validate();

Для получения сообщений об ошибках после валидации в CI используется функция validation_errors(), вызов которой располагается, как правило, на формой, проверка которой осуществляется.

В Kohana для получения сообщений об ошибках используется метод errors(), который возвращает массив сообщений.

$validator->errorrs();
  1. Как правило, если возникли ошибки при проверки данных формы - необходимо заново отобразить эту форму, оставив заполненные поля нетронутыми (т.е. не "сбрасывать" форму), для возможности корректировки данных. В CI для этого используется функция <strong>set_value($fieldName)</strong> , где $fieldName - название поля. Пример (фрагмент HTML-формы):
  2. <pre lang="PHP"><input name="userName" type="text" value="<?= set_value('userName')?>" />

В Kohana применяется метод as_array(), который вернет массив полей формы:

$validator->as_array();
  1. Для передачи этого массива во view (для заполнения полей) можно использовать следующий код
  2. <pre lang="PHP">View::factory('testview')->set('form',$form)->render(TRUE);

Фрагмент формы:

Краткий вывод и мое личное мнение: Механизм валидации форм в CI мне понравился гораздо больше чем в Kohana (из-за своей простоты и прозрачности), однако хотел бы отметить одну особенность Kohana - возможность задавать фильтры пост и пред-обработки данных глобально, для всех проверяемых полей - очень не хватает такой возможности в CI.

На этом мой краткий обзор средств и методов валидации форм в CI и Kohana заканчивается.
До новых встреч!

похожие записи:

Комментарии

  • Евгений
    29 декабря 2008 - 09:12 | Permalink

    Хороший пост! хоть и плохо знаком с предствленными фреймворками, но все интуитивно понятно, а главное просто.
    Советую посмотреть работу с формами в symfony fw.

  • 29 декабря 2008 - 16:12 | Permalink

    @Евгений
    Спасибо за совет! Symfony при возможности посмотрю!

  • homm
    21 февраля 2009 - 20:02 | Permalink

    Есть 2 замечания, которые в корне, на мой взгляд, меняют суть дела.
    1) В Кохане валидатор идет отдельно от форм. Вы можете провалидировать любые данные. Помимо самого простого варианта с мержем $_POST с $_GET или $_FILES это может быть полезно при импроте данных из внешних источников.

    2) add_callbacks устанавливает действительно callbacks, функцию которой передается весь валидатор и которая самостоятельно устанавливает ошибки валидации. Чтобы просто проверить переменную в любой функции, достаточно просто написать имя этой функции или array(‘class’,’method’). Таким образом add_callbacks — это не неудобный способ делать привычные вещи, а дополнительныная возможность в сложных ситуациях.