Архив метки: codeigniter

Производительность Kohana, Codeigniter,Yii

В сети появилось множество тестов сравнения производительности популярных PHP-фреймворков, каждый из которых старается доказать что он лучший и следует выбрать именно его. Мне стало это интересно и я решил провести свой маленький тест.

Я сравнивал  Kohana 2.3.1, Codeigniter 1.7Yii 1.0.1.

Все это «хозяйство» запускалось под xampplite на моем Eee PC 701 (да да да именно Eee PC 701 !!!!!), работающем под Windows XP.

Тестовым приложением был сам фреймворк, т.е. для Kohana и Ci я просто произвел их установку и первичную настройку (тестировалось обращение к дефолтной странице установленного фреймворка). Для тестирования Yii было создано тестовой приложение ( команда yiic webapp  docRoot/yiiTest), обращение происходило к индексной странице этого приложения.

Результаты тестирования можно видеть на скриншотах ниже.

Производительность Codeigniter ~ 110 rps

Производительность Codeigniter ~ 111 rps

Производительность Kohana ~ 111 rps

Производительность Kohana ~ 112 rps

Производительность yii ~ 135 rps

Производительность yii ~ 134 rps

Как видно из проведенных тестов, все «испытуемые» показали приблизительно одинаковую производительность, однако Yii незначительно вышел вперед.

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

Да, чуть не забыл, команда для тестирования: ab -t 10 -c 10.

обсудить

xjslib 0.0.1

Так уж получилось, что я сейчас пишу диплом. Задание заключается в разработке JavaScript библиотеки для построения пользовательского интерфейса (что-то типа маленького Extjs). Одним из пунктов задания является возможность  указывать правила валидации для всех необходимых полей ввода и делать это  в «удобном и простом» виде. Поразмыслив над этой задачей, я решил выделить валидацию в отдельный модуль (класс), который можно будет использовать отдельно от всей, разрабатываемой мною библиотеки.

Так как у меня есть некоторый опыт программирования на Codeigniter, и использования его библиотеки для валидации данных (и на мой взгляд подход, выбранный в CI, является «удобным и простым») за основу своего модуля я решил взять form_validation из CI. Сразу отмечу, что до написания диплома я использовал  JavaScript, примерно на 5-10% от всех его возможностей (для решения каких-то простых и элементарных задач).  Собственно говоря, желание лучше освоить JS и подтолкнуло меня взять на диплом именно эту тему.  После приобритения замечательной книги по JS, я начал потихонечку обдумывать и разрабатывать свой проект.

И вот свершилось ))).  Хочу представить вашему вниманию мой первый модуль на JavaScript — xjslib(что значит xjslib — ничего более оригинального я не придумал )))) — библиотека валидации форм.  Поискав в Google материал на тему  Codeigniter+JavaScript я нашел интересную ссылочку.  Рассмотрев эту библиотеку для CI, я взял ее за основу для своей собственной библиотеки валидации форм.

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

И кое-что новое я узнал:

Буду очень признателен за критику кода, функционала и вообще за любые замечания.

Для библиотеки xjslib будет существовать постоянная страничка в моем блоге.

Сейчас доступна версия xjslib 0.0.1. С примером использования можно ознакомится здесь.

Как говорится, welcome !

Codeigniter vs Kohana ||

VS

Codeigniter vs Kohana ||

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

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

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

Начнем с Codeigniter.

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

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

$this->load->library('form_validation');

— стандартная процедура загрузки библиотеки для CI. После этого все действия можно выполнять, обращаясь к

$this->form_validation->some_method();

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

$validator = new Validation($_POST);

$array = array_merge($_POST,$_GET); // объединем $_GET и $_POST для проверки

$validator = new Validation($array);

$validator = Validation::factory($_POST) // вызов статичного метода

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

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

$this->form_validation->set_rules($field,$name,$rules)

$field — имя поля в массиве $_POST;

$name — псевдоним поля — это значение появится в сообщении об ошибке

$rules — правила валидации

Подробнее о правилах валидации…

Помимо собственно правил проверки, можно задать правила (или фильтры) для пред-обрабокти и/или пост-обработки данных.

Например, рассмотрим следующее правило:

«trim|required|strtolower»

Символ «|» используется для объединения правил — в терминах CI «каскадирование». Итак…

  • trim — стандартная функция php, которая удаляет все начальные и конечные пробелы
  • required — одно из встроенных правил CI, которое делает поле обязательным для заполнения
  • strtolower — стандартная функция php, которая переводит все символы в нижний регистр

Таким образом в этом правиле…

  • trim – функция, которая вызовется перед проверкой поля (пред-обработка)
  • required — само правило валидации
  • strtolower — функция, которая вызовется после проверки поля (пост-обработка)

Последовательность действий, которые выполнит CI будет следующая:

  1. выполнится функция trim
  2. выполнится проверка на заполнение поля (required)
  3. строка трансформируется в нижний регистр и запишется в массив $_POST(свое исходное место)

Нужно отметить очень важный момент:

Все функции пред- и пост-обработки в CI изменяют глобальный массив $_POST, т.е. данные модифицируются непосредственно в источнике.

В качестве правил обработки могут выступать любые PHP функции, принимающие один параметр.

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

В Kohana для установки правил валидации используется похожий метод:
add_rules($field, $rule, $rule…,…,…)

$field – поле для проверки
$rule – правило проверки

Пример:

$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’,’email’) // стандартный способ
$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 для задания собственного правила необходимо

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

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

public function checkName($str){

………..

………..

………..

}

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

$this->form_validation->set_rules('userName','имя','trim|strtolower|callback_checkName');

Рекомендация. Так как функция проверки будет являться методом текущего контроллера, для того что-бы она не была доступна через URL сайта, необходимо сделать ее «приватной». Для CI (см статью 1). это означает, необходимость перед именем функции добавить префикс «_»

Kohana использует похожий принцип, однако на мой взгляд, он менее очевиден.
И так. Для задания собственного правила проверки необходимо:

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

Для установки собственного правила необходимо вызвать метод add_callbacks()

Пример:

$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','Укажите корректное имя пользователя')

— данный код устанавливает текст сообщения об ошибке для пользовательской функции проверки «checkName». CI хранит сообщения об ошибках в языковом файле, при необходимости тексты сообщений можно изменить.

В Kohana необходимо вызвать метод add_error():

$validation->add_error($field,$errorMsg);

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

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

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

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

$this->form_validation->run();

В Kohana используется метод validate(), так же возвращает FALSE при неудачной валидации;

$validator->validate();

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

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

$validator->errorrs();

Как правило, если возникли ошибки при проверки данных формы — необходимо заново отобразить эту форму, оставив заполненные поля нетронутыми (т.е. не «сбрасывать» форму), для возможности корректировки данных. В CI для этого используется функция set_value($fieldName) , где $fieldName — название поля. Пример (фрагмент HTML-формы):

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

$validator->as_array();

Для передачи этого массива во view (для заполнения полей) можно использовать следующий код

View::factory('testview')->set('form',$form)->render(TRUE);

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

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

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

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 этого фреймворка.