Kohana *

Приветствую всех.

Уже довольно давно разрабатываем проект на кохане и встала необходимость эффективного кэширования данных. Не то, чтобы вопрос производительности стоит очень остро в данный момент, но, хотелось бы подготовится заранее, а не писать систему кэширования в ночь после волны посетителей. Да и посещаемость постоянно растет, а в некоторые моменты бывают всплески до 3х раз по сравнению с обычным днем.

Собственно, в выборе системы кэширования особых вопросов не было — на ум сразу приходит всем известный memcached.

Если вы хотя бы немного смотрели memcached, то должны были отметить, что, по большому счету, он поддерживает только 2 операции: получение значения, запись значения. Нет никакой возможности вытянуть все ключи по определенному признаку или паттерну. Сделано это сознательно, с целью сделать его максимально простым, а значит, максимально быстрым.

Итак, представим ситуацию, что мы храним в кэше данные записей блога под ключами post_. В определенный момент нам требуется сбросить все записи с постами, при этом не очищая кэш полностью (там могут хранится другие данные, значения которых все еще актуальны). Ситуация получается безвыходная. Мы не знаем список ключей постов, получить их нет возможности, сбросить ключи по паттерну тоже невозможно. Что же делать?

Здравствуйте,

После выхода Kohana 3 хочется ее использовать в новых проектах, и использование Doctrine показало, что инструмент очень удобный, потому поделюсь рецептом интеграции.

Не так давно вышла третья версия этого фреймворка. Еще до его выхода я делал небольшой обзор новых возможностей. Тогда я обошел тему роутинга и HMVC, но сегодня готов исправиться.

Как-то странно, что на Хабре еще нет такой новости, но это может быть связанно с тем, что Москва просыпается немного позже Сибири.

Итак, собственно, свершилось — широко известный в узких кругах PHP фреймворк Kohana наконец переступил порог мажорных версий еще раз, и во всеобщий доступ выложен Kohana 3.0 final.

Обширного чейнджлога, кроме обещаний написанных в посте homm'а я пока не нашел, но от этого новость менее радостной не становится. Собственно:

Ссылка на тред с обсуждениями
Ссылка для скачивания
Ссылка на задачи

Апдейт от dohlik
1. Мануал на английском
2. Cобственно исходники на гитхабе, можно форкать и дополнять, в том числе и переводить на русский

Как-то так получилось, что примерно месяц я не следил за разработкой этого замечательного фреймворка. Наблюдение за скоростью разработки версии 2.4 вызывало тоску. Но вчера я заглянул на сайт и ахнул. Оказывается, разработчики, не дождавшись готовности версии 2.4, успели уже выпустить целых 2 релиз кандидата версии 3. Глянул я в исходные тексты, немного почитал форум и стало мне так радостно на душе от грядущих изменений, что я решил не дожидаться 09.09.09 или ранее и поделиться радостью.

Итак, в предыдущем топике (виден только подписчикам блога!) я ссылался на статью о Kohana, размещенную на сайте NetTuts+. Поскольку в описанном в ней приложении есть недостатки, предлагаю их найти и обезвредить.

В Kohana я обычно использую класс Template_Controller. Очень удобно — layout один, изменяешь только контент. Но как быть если на одной какой-то странице нам понадобилось подключить CSS- или JS-файл?! C js- файлом еще ладно, его можно подключить посредине страницы (но это как-то некрасиво), а как же css?! — это невалидно. Подключать на весь layout тоже неохота. Хочу подключать не в контроллере, а в шаблоне к примеру так:

Copy Source | Copy HTML

1. <?php head::addCSS('main')?>

Возникал такая проблема. Для разных разделов веб-приложения необходимо было хранить состояния наборов параметров. Далеко ходить не нужно: значения в сессии или куки. Но управление значениями улжнилось тем, что при выходе из раздела состояния должны были терятся.

Ничего особо финтового в примере нет. Просто хелпер из трех функций: одна устанавливает состояние параметра, одна возвращает, одна сбрасывает. Значения храним в сессии.
Основная идея — в том что имя контроллера так же хранится в сессии, и при обращении к состоянию проверяется совпадение имени «последнего» контроллера и «активного». Если совпадают — возвращаем состояние. Если нет — устанавливаем дефолтовые значения состояний и возвращаем дефолтовое.

Такая схема позволяет:

• свести работу с состояниями к статическому контроллеру и не оперирывать живыми переменными
• вынести установку дефолтовых значений всех состояний системы в одно место

Вашла новая версия замечательного фреймворка. Исправлено около 70 багов.

Список изменений

Ссылка для скачивания

При обновлении — заменяем у себя только папки system и modules

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

Конечно мы не можем себе позволить обращаться к области данных из шаблона, иначе это указывало бы на нашу неграмотность. Во многих фрейверках есть для этого свои решения. Но я проведу аналогию с symfony. В последнем имеется такое понятие как компонент. Выглядит это примерно так: вы вызываете в шаблоне статический метод с указанием названия компонентов, далее происходит обращение к одноименному контроллеру, извлекаются данные из области данных и передаются в фрагмент шаблона, последний рендерится и код вставляется в нативный шаблон. Таким образом получается архитектура MVC вложенная друг в друга. Я немного упростил эту схему, сразу говорю, но суть передал точно.

Так вот. В Kohana готового решения нет. Поэтому я и написал простой способ реализации компонентов который решается в три строчки кода.

И так. Пишем хелпер widget.php и кидаем его в папку application/helpers. Содержание хелпера следующее:

Copy Source | Copy HTML

1. <?php
2. class widget
3. {
4.     public static function paste($className,$functionName,$parameters = null)
5.     {
6.         $controllerName = $className.'_Controller';
7.         $controller = new $controllerName;
8.         $controller->$functionName($parameters)->render(true);
9.     }
10. }
11. ?>

В классе контроллера пишем метод обычного содержания только вместо рендеринга шаблона мы его возвращаем т.е пишет return. Я всегда использую немного переопределенный контроллер Template_Controller. Пример метода контроллера:

Copy Source | Copy HTML

1. public function widget_example()
2. {
3.     return View::factory('_example.php',array('var' => 'Привет мир!'));
4. }

Имя шаблона указываем с нижнего подчеркивания, что бы не путаться.
Теперь в любом шаблоне достаточно написать

Copy Source | Copy HTML

1. <?php widget::paste('Index','widget_example')?>

И все — теперь вместо этой строки у нас отрендерится наш виджет. Вот так вот просто. Если необходимо то можем передать в компонент необходимые значения третьим аргументом в виде массива.
Кстати partial (symfony like) реализовываются простым включением в шаблон

Copy Source | Copy HTML

1. <?php View::factory('template')->render() ?>

partial — это простое включение шаблона (для тех кто не знает)
P.S. Только давайте не будем разводить холивары по поводу Smarty(и т.п.) vs Native Template.
Есть много наработок по поводу Kohana — со временем опубликую цикл статей на блоге и здесь.
UPD. Перенести пост в блог Kohana немогу. Не хватает кармы

Debug Toolbar — это модуль для Коханы, который упрощает отладку приложений, написанных на этом PHP-фреймворке. Благодаря различной статистической и отладочной информации, процесс разработки становится проще и приятней для программиста.

Под катом краткая инструкция по установке, описание возможностей и ссылки на дополнительную информацию.

Речь пойдет о первом моем модуле для фреймворка Kohana.


Признаюсь честно, при первом и последующих взглядах на этот фреймворк он мне очень понравился. Но как известно нет ничего идеального. Как мне показалось, одно из самых слабых мест в Кохане — довольно примитивные представления (View). По сути они предствляют из себя plain-php файл с экспортированными в глобальную область видимости переменными и доступным по ссылке $this контроллеру. Это очень удобно, когда вам нужно представление для вывода данных, нет ничего лишнего, можно сосредоточиться на коде. Но когда нам нужно вывести макет страницы со сложным расположением элементов, которые могут меняться от раздела к разделу… Что делать? Собирать все из мелких вьюшек в контроллере? Не удобно, особенно если контроллеров много — не дай бог, например, поменяется количество столбцов в разметке, придется в каждом контроллере перераспределять блоки с контентом по столбцам. Наверное по этому в версии 2.4 появится (я надеюсь) модуль интеграции со Смарти.

Kohana — довольно молодой PHP фреймворк, форк CI, всецело завязанный на ООП. К достоинствам Kohana можно отнести использование всех возможностей PHP5 на 100%, высокую скорость работы, «легковесность» и простоту как использования, так и изучения. Из минусов отчетливо выделяется небольшое комьюнити, как следствие, не шибко качественная документация и небольшое количество модулей и библиотек.

Не так давно своё знакомство с фреймворками я начинал именно с Kohana и, надо сказать, я был удивлен, насколько легко он мне поддался. Думал будет намного сложнее. Но очень сказывалась нехватка документации и примеров кода. Зарывшись в маны и разбор исходников, через некоторое время, я восполнил интересующие меня пробелы относительно Kohana, и поэтому решил написать эту статью, дабы другим хабралюдям, оказавшимся в схожей ситуации не пришлось по ночам не досыпать и лечить головные боли.

Под катом пример доски объявлений, написанный с помощью Kohana, возможно местами он не претендует на рациональность и здравый смысл, но всё-же я надеюсь услышать конструктивную критику.

Статья рассчитана на людей, имеющих понятие об MVC и ООП, но не имевших, либо мало имевших, дело с фреймворками.

Вышел релиз фреймворка Kohana 2.3. Внутри список изменений на русском.

Приветствую тебя, Хабрачеловек.

Полторы недели я пишу небольшой проект на Kohana. Сегодня решил немного рассказать об этом замечательном PHP-фреймворке и некоторых его особенностях, а также поделиться субъективными впечатлениями от работы. Надеюсь, кому-нибудь этот пост окажется полезен, особенно учитывая тот факт, что информации о Кохане в сети пока очень мало.

Итак.

Делаем то же самое что и здесь, только используя Kohanaphp:

Отличия kohanaphp от codeigniter:

* Использует PHP 5 ООП
* Абстракция базы данных, используя SQL helpers
* Разнообразные драйвера сессий (native, database и cookie)
* Обработчик событий
* Основан на базе CodeIgniter
Получить kohana можна на сайте kohanaphp.