Codeigniter vs Kohana ||
VS
Codeigniter vs Kohana ||
Раунд 2. Проверка форм
Вторая часть фреймворка, которая на мой взгляд, является очень важной — это средства и возможности проверки корректности данных, введенных пользователем или иными словами — валидация форм.
Оба фреймворка имееют достаточно развитые возможности проверки данных, о них я сегодня и постараюсь рассказать.
Начнем с Codeigniter.
Совсем недавно вышла версия 1.7 данного фреймворка, класс для проверки данных, претерпел существенные изменения, поэтому все описанное ниже относится только к последней версии CI.
И так… для того что бы библиотека валидации форм была доступна в Ваших контроллерах (как правило именно там и происходит валидация) необходимо выполнить следующее:
-
- стандартная процедура загрузки библиотеки для CI. После этого все действия можно выполнять, обращаясь к
-
<pre lang="PHP">$this->form_validation->some_method();
Kohana
Kohana предлагает несколько вариантов:
-
-
$array = array_merge($_POST,$_GET); // объединем $_GET и $_POST для проверки
-
-
$validator = new Validation($array);
-
-
$validator = Validation::factory($_POST) // вызов статичного метода
После того как библиотеки загружены, необходимо указать правила валидации полей - то, собственно ради чего все это и затевалось...
В CI для установки правил валидации используется метод set_rules()
-
$field - имя поля в массиве $_POST;
-
-
$name - псевдоним поля - это значение появится в сообщении об ошибке
-
-
$rules - правила валидации
-
-
Подробнее о правилах валидации...
-
-
Помимо собственно правил проверки, можно задать правила (или фильтры) для<strong> пред-обрабокти</strong> и/или <strong>пост-обработки</strong> данных.
-
-
Например, рассмотрим следующее правило:
-
-
<strong>"trim|required|strtolower"</strong>
-
-
Символ "|" используется для объединения правил - в терминах CI "каскадирование". Итак...
-
<ul>
-
<li> trim - стандартная функция php, которая удаляет все начальные и конечные пробелы</li>
-
<li> required - одно из встроенных правил CI, которое делает поле обязательным для заполнения</li>
-
<li> strtolower - стандартная функция php, которая переводит все символы в нижний регистр</li>
-
</ul>
-
Таким образом в этом правиле...
-
<ul>
-
<li> trim – функция, которая вызовется перед проверкой поля (пред-обработка)</li>
-
<li> required - само правило валидации</li>
-
<li> strtolower - функция, которая вызовется после проверки поля (пост-обработка)</li>
-
</ul>
-
Последовательность действий, которые выполнит CI будет следующая:
-
<ol>
-
<li>выполнится функция trim</li>
-
<li>выполнится проверка на заполнение поля (required)</li>
-
<li> строка трансформируется в нижний регистр и запишется в массив $_POST(свое исходное место)</li>
-
</ol>
-
Нужно отметить очень важный момент:
-
<blockquote><span style="color: #ff6600;">Все функции пред- и пост-обработки в CI изменяют глобальный массив $_POST, т.е. данные модифицируются непосредственно в источнике.</span></blockquote>
-
В качестве правил обработки могут выступать любые PHP функции, принимающие один параметр.
-
-
Кроме того правила валидации для полей можно задавать через массив, собирая все правила в одном массиве, а так же, правила можно сохранять в конфигурационный файл, для последующего использования (подробнее об этом можно прочитать в документации CI).
-
-
В <strong>Kohana</strong> для установки правил валидации используется похожий метод:
-
<strong>add_rules($field, $rule, $rule...,...,...)</strong>
-
-
$field – поле для проверки
-
$rule – правило проверки
-
-
Пример:
-
<pre lang="PHP">$validator = new Validation($_POST);
-
$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’,’valid::email’) // явно указав правило
-
$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 для задания собственного правила необходимо
- написать функцию, которая будет выполнять проверку
- установить правило валидации для поля формы
Функция может выполнять абсолютно любые действия, соединяться с БД, читать из файла и т.д.
-
-
………..
-
-
………..
-
-
………..
-
-
}
Для установки собственно правила необходимо указать имя функции, предварив его префиксом «callback_»
-
<blockquote><span style="color: #ff6600;">Рекомендация. Так как функция проверки будет являться методом текущего контроллера, для того что-бы она не была доступна через URL сайта, необходимо сделать ее «приватной». Для CI (см статью 1). это означает, необходимость перед именем функции добавить префикс "_"</span></blockquote>
-
<strong>Kohana</strong> использует похожий принцип, однако на мой взгляд, он менее очевиден.
-
И так. Для задания собственного правила проверки необходимо:
-
<ul>
-
<li> написать функцию, которая будет выполнять проверку</li>
-
<li> установить правило валидации для поля формы</li>
-
</ul>
-
Для установки собственного правила необходимо вызвать метод <strong>add_callbacks()</strong>
-
-
Пример:
-
<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' - текст сообщения
Пример:
-
- данный код устанавливает текст сообщения об ошибке для пользовательской функции проверки "checkName". CI хранит сообщения об ошибках в языковом файле, при необходимости тексты сообщений можно изменить.
-
-
В Kohana необходимо вызвать метод <strong>add_error()</strong>:
-
<pre lang="PHP">$validation->add_error($field,$errorMsg);
$field - проверяемое поле
$errorMsg - сообщение об ошибке
Так же как и CI, Kohana позволяет сохранять тексты сообщений об ошибках во внешних файлах.
Для запуска процесса валидации в CI используется метод run(), который при наличии ошибок - вернет FALSE:
-
В Kohana используется метод validate(), так же возвращает FALSE при неудачной валидации;
-
<pre lang="PHP">$validator->validate();
Для получения сообщений об ошибках после валидации в CI используется функция validation_errors(), вызов которой располагается, как правило, на формой, проверка которой осуществляется.
В Kohana для получения сообщений об ошибках используется метод errors(), который возвращает массив сообщений.
-
Как правило, если возникли ошибки при проверки данных формы - необходимо заново отобразить эту форму, оставив заполненные поля нетронутыми (т.е. не "сбрасывать" форму), для возможности корректировки данных. В CI для этого используется функция <strong>set_value($fieldName)</strong> , где $fieldName - название поля. Пример (фрагмент HTML-формы):
-
<pre lang="PHP"><input name="userName" type="text" value="<?= set_value('userName')?>" />
В Kohana применяется метод as_array(), который вернет массив полей формы:
-
Для передачи этого массива во view (для заполнения полей) можно использовать следующий код
-
<pre lang="PHP">View::factory('testview')->set('form',$form)->render(TRUE);
Фрагмент формы:
Краткий вывод и мое личное мнение: Механизм валидации форм в CI мне понравился гораздо больше чем в Kohana (из-за своей простоты и прозрачности), однако хотел бы отметить одну особенность Kohana - возможность задавать фильтры пост и пред-обработки данных глобально, для всех проверяемых полей - очень не хватает такой возможности в CI.
На этом мой краткий обзор средств и методов валидации форм в CI и Kohana заканчивается.
До новых встреч!
Фреймворки «не любят» RSS.
Фреймворки «не любят» RSS.
Сегодня наконец-то я добрался до своего Google Reader-а и решил навести там порядок (разложить все по папочкам, удалить все ненужное и прочее..) Кроме того решил все подписки касаемые php-фреймворков перенести в отдельный каталог, для организованности так сказать…Пробегая по официальным сайтам следующих fw: CakePhp, Codeigniter, Symfony, Kohana, новенький yii, я был очень удивлен тем, что лишь CI и Symfony пердоставляют Rss-ленту на своих сайтах (rss лента добавлялась, путем копирования главного url сайта фреймворка в форму добавления подписки в Google Reader-e), на сайтах всех остальных фреймворков приходилось любоваться надписью:
«Не найдены каналы, соответствующие условию поиска….»
Конечно, может быть, подписка где-то в глубине сайта и есть, но на мой взгляд, ее можно было бы перенести в корень!
CI и Symfony — маленькие победитель в моем маааааальньком тесте!
yii framework
На днях прочитал заметку о фреймворке yii.
Решил подробнее с ним ознакомтся.
Сразу отмечу никаких реальных приложений (за исключением hello world) я на нем не писал (да и не успел бы…так как узнал о его существовании совсем недавно)….
Так же сразу оговорюсь…до этого момента я имел дело лишь с CI и совсем немного с Kohana, так что сравнивать кроме как с этими двума фреймворками — больше не с чем…
Большинство выводов, которые будут привидены в этой небольшой статье основаны только на подробнейшей документации по данному фреймворку, но никак не на его реальном использовании.
И так поехали…Что мне понравилось
1) Генерация кода - некоторые скажут что это бесполезная функция, однако не имея таковой в CI, пользоваться ей в Yii было приятно. Для генерация всего и вся используется скриптик yiic (так же есть что-то типа интерактивного шела), с помощью которого можно сгенерировать многое, от моделей и контроллеров, до «скелета» целого приложения и CRUD операций с данными в БД.
2) Контроллеры (controllers) — понравилось что в контроллере можно назначать действие по умолчанию, в CI и Kohana — действие по умолчанию — index.
3) Действия (actions) - действием может быть как метод контроллера (стандартный вариант) так и отдельный класс. Действие оформленное в виде отдельного класса позволяет использовать свои возможности в любом месте приложения — иногда может оказаться полезным.
4) Представления (view) — как и раньше это просто HTML файлы со вставками php кода. Понравилось что по умолчанию yii ищет view-файлы в подкаталоге, имя которого совпадает с ID контроллера (например для контроллера userController, view — файлы будут искаться в каталоге …view/user/…). Так же порадовало наличие Layout — общего view для всех страниц приложения — часто приходится делать это ручками.
5) Фильтры (Filter) — вот что действительно мне очень понравилось. Фильтры позволяют выполнить произвольный код перед и/или после того как будет выполнено действие контроллера, при необходимости фильтр может отменить выполнение действия. Фильтром может служить как метод контроллера так и отдельный класс, кроме того можно явно указать какие действия контроллера необходимо «фильтровать» а какие нет. Фильтров для конкретного действия может быть сколько угодно. Очень удобно применять один и тот же фильтр для всех контроллеров приложения, например для проверки авторизации пользователя.
Судя по официальному сайту реализация фильтров была позаимствована из symfony — так как я не знаком с данным фреймворком — ничего по этому поводу сказать не могу.
6) Модели (models) — модели используют ORM для взаимодействия с БД, для меня, писавшего некоторое время на CI и не видевшего ORM раньше — данный подход показался довольно интересным. Кроме ORM можно использовать DAO (в терминах yii), этот метод позволяет sql- писать запросы «ручками».
7) Пути и пространства имен. yii позволяет создавать алиасы для реальных путей файловой системы.
Есть возможность импортировать отдельные классы и даже целые каталоги классов, используя синтаксис очень напоминающий JAVA.
Напимер:
Yii::import(‘system.web.CController’);
Yii::import(‘system.web.*’);
Система кеширования — позволяет кэшировать как отдельные переменные и фрагменты страниц, так и целые страницы.
Вот наверное и все что мне запомнилось после беглого прочтения документации, однако на самом деле возможности фреймворка не ограничиваются этим списком.
Я не упомянул здесь развитую систему «логирования» (кстати у меня так и не получилось записать сообщение в лог файл — может ручки кривые))), систему роутинга и многие другие возможности.
Кроме того базовые возможности фреймворка можно расширить использованием сторонних библиотек.
На первый взглад фреймворк очень достоин дальнейшего изучения и приминения на деле (если не будет серьезных ошибок)!
Codeigniter vs Kohana
VS
Раунд 1 MVC.
Kohana
При объявлении собственного конструктора в контроллере, необходимо вызвать конструктор базового класса, так как Kohana основан на ООП и PHP 5 синтаксис этого вызова следующий:
-
parent::__construct()!
в отличии от
-
parent::Controller()
в Codeigniter.
В отличии от Codeigniter, Kohana требует что бы в наименование класса контроллера присутствовал постфикс «_Controller», не указав который, при обращении к контроллеру получаем сообщение об ошибке «Fatal error: Cannot redeclare class ».
На мой взгляд, это не совсем удобно, так как разработчик может иметь собственные правила именования классов, которые ни как не пересекаются с правилами Kohana. Однако это позволяет избежать конфликтов имен, в тех случаях, когда класс контроллера и, например, модели, называется одинаково.
Для обозначения методов, доступных только внутри контроллера (не доступных с сайта), Codeigniter предлагает использовать префикс «_» в названии метода.
Пример:
-
public function _some_action() - метод недоступный для вызова через URL сайта.
Kohana предлагает два варианта решения этой проблемы (один из которых наиболее интуитивен, по моему мнению), а именно:
можно объявить метод как private — такой метод недоступен через URL сайта
Пример:
-
private function some_action() - приватный метод контроллера.
как и в Codeigniter можно объявить закрытый метод с префиксом «_»
Пример:
-
public function _some_action()
- так же приватный метод.
Можно комбинировать два этих способа и объявить метод следующим образом:
-
private function _some_action()
Контроллер в Codeigniter может содержать еще две функции, аналога которых пока нет в Kohana:
_remap($method) — данная функция предназначена для локального роутинга, т.е. перенаправления на другие контроллеры приложения. В качестве параметра ей передается запрошенный в URL метод.
_output($out) - функции передается обработанное отображение, предназначенное для отсылки браузеру. Данная функция может быть использована для конечной обработки вывода.
Отображения (VIEW)
В обоих фреймворках отображения (или предстваления, или view) — это просто PHP сценарии, содержащие в основном HTML-код. Однако способ работы с отображениями кардинально отличается в этих фреймворках.
Codeigniter
Для загрузки файла отображения из контроллера используется вызов метода:
-
$this->load->view(«view_file»);
view_file — имя файла отображения без расширения «php».
В Codeigniter одновременно с загрузкой происходит и вывод отображения в браузер пользователя.
Для передачи параметров в представление, используется следующий вызов:
-
$this->load->view(«view_file»,$some_data);
где $some_data — ассоциативный массив содержащий параметры для отображения.
Пример:
-
$some_data['user_fname'] = 'Андрей';
-
$some_data['user_lname'] = 'Опейкин';
Если файл отображения будет содержать следующий код:
<html>
<body>
<h1>Привет $user_fname $user_lname!</h1>
</body>
</html>
То «отрендеренное» отображение (страничка, которую увидит пользователь) будет выглядеть так:
<html>
<body>
<h1>Привет Андрей Опейкин!</h1>
</body>
</html>
Кроме ассоциативного массива в качестве второго параметра метода, можно передавать объект, свойства которого, заменяют соответствующие переменные в отображении.
На мой взгляд недостатком такого подхода является то, что при загрузке отображения, автоматически происходит его отправка в браузер пользователя. Для перехвата вывода необходимо использывать метод контроллера _output() - описанный ранее, так же получить (а не вывести в браузер) полностью готовое отображение можно передав третий параметр в метод загрузки представления:
-
$page = $this->load->view(«view_file»,$some_data,TRUE); // содержимое присваивается переменной $page
Kohana
Для загрузки файлов отображений существует два способа:
Использование конструктора класса View
Пример:
-
$view = new View(«view_file»);
Вызов статичного метода (метод фабрики)
Пример:
-
$view = View::factory(«view_file»);
В обоих случаях «view_file» — имя файла отображения.
Использование любого из этих способов, приводит лишь к созданию объекта отображения, вывод содержимого отображения в браузер пользователя НЕ происходит.
Воспользуемся примером отображения, описанного выше.
Для передачи параметров в отображение используется объектный подход.
-
$view->user_fname = 'Андрей';
-
$view->user_lname = 'Опейкин';
Так же можно передать параметры методом set();
-
$view->set('user_fname','Андрей');
-
$view->set('user_lname','Опейкин');
Установка параметров отображения так же как и создание объекта отображения НЕ приводит к пересылке информации пользователю.
Для отправки вывода пользователю необходимо вызвать метод render() отображения
-
$view->render(TRUE);
На мой взгляд подход Konaha удобнее и практичнее.
Модели (Models)
В обоих фреймворках использование моделей НЕ является обязательным. При желании можно обойтись контроллерами и представлениями.
Kohana
Как и в случае с контроллерами, требует, чтобы класс модели имел определенный постфикс — «_Model».
Пример:
-
class User_Model extends model
-
-
………
-
-
}
Для загрузки модели из контроллера, необходимо просто создать экземпляр класса модели:
-
$user = new User_model();
После этого можно обращаться ко всем методам и свойствам данного объекта.
Если в конструкторе модели вызывается родительский конструктор, т.е. конструктор имеет вид:
-
public function __construct(){
-
parent::_construct();
-
………………………….
-
}
Автоматически загружается класс для работы с базой данных, доступный как
-
$this->db
Codeigniter
Для загрузки класса модели необходимо использовать следующий код:
-
$this->load->model(«model_name») ;
После этого к методам модели можно обращаться следующим образом:
-
$this->model_name->some_method();
Объект для работы с базой данных НЕ создается автоматически при загрузке модели, для того что бы объект все таки создался, необходимо передать значение TRUE в качестве третьего аргумента:
-
$this->load->model(«model_name»,'',TRUE) ;
Второй аргумент определяет псевдоним модели, по которым она будет доступна в контроллере.
Вся информация о фреймворке Kohana взята из соответствующей документации. Могут быть некоторые неточности, так как документация еще находится в процессе разработки и описывает далеко не все возможности и API этого фреймворка.
