$user->has('roles', array(1, 2)); // FALSE
$user->has_any('roles', array(1, 2)); // TRUE
$user->count_relationships('roles', array(1, 2)); // 1

Auth ORM

• При нестандартном имени ключа в модели User попытка создания пользовательского токена (т.е. логин с $remember==TRUE) приводила к ошибке. #4222

Базовые изменения

• Исправлено зацикливание с последующей ошибкой out of memory. Если в системе добавлен Database Config Reader, то он теперь не пытается считывать настройки подключения к БД (отсекается группа настроек ‘database‘). #4316
• Для определения необходимости ведения статистических замеров (profiling) модуль теперь использует централизованную настройку Kohana::$profiling (устанавливается в Kohana::init()). В 3.2 модуль Database имел собственный параметр ‘profiling‘ в конфиге. #4203
• В методах compile($db) семейства классов Database_Query параметр $db сделан опциональным. Кроме того, он может являться не объектом Database, а строкой (т.е. именем соответствующего профиля в конфиге). Такая логика уже присутствовала в методе execute($db). #3872
  

  Напомню, метод compile() преобразовывает условия запроса Query_Builder‘а в SQL-строку, но не выполняет запрос, а возвращает сгенерированный текст.

• В Query_Builder появился еще один метод для работы с группами условий. В 3.2 имеются методы where_open(), and_where_open(), or_where_open() и where_close(). Они позволяют объединять условия в группы, например WHERE (`a` > 0 OR `b` < 0) AND `c` == 1. Иногда возникает потребность формировать такие группы условий динамически (например, обработка данных с формы поиска). И может возникнуть ситуация, когда группа создана (вызваны методы where_open() и where_close()), а внутри условий нет. Во избежание подобных ситуаций был добавлен метод where_close_empty(). Если внутри группы есть хоть одно условие, то он действует аналогично where_close(). #4052
• Database-драйверы для Config и Session, а также модели (Model_Database) по умолчанию теперь используют профиль Database::$default. Ранее было жестко прописано значение 'default'. #4289
• Повышено качество phpDoc-комментариев.

PDO

• В драйвер PDO можно передать дополнительные параметры (см driver_options). Используйте ключ ['connection']['options']. #4372
• Для PDO параметр 'charset' в конфиге неактулен. Устанавливайте его через DSN, либо в доп. параметрах (['connection']['options']['charset']). #4078

PS. Пока негусто. Если в последующих RC или в финальной версии будут еще изменения, они будут добавлены в данную статью.

Правила именования файлов

• Поддержка стандарта PSR-0 привела к тому, что все имена файлов классов в Kohana 3.3 должны начинаться с большой буквы. В регистрочувствительных системах (т.е. все кроме Windows) это важно.
• Для корректной работы старых модулей, не приведенных к новому стандарту имен файлов, добавили метод Kohana::auto_load_lowercase(). Просто добавляете его к стандартному автозагрузчику в bootstrap.php и можно продолжать работать:

  spl_autoload_register(array('Kohana', 'auto_load_lowercase'));

• Добавилась поддержка namespace‘ов в именах классов. Правила все те же – namespace (если он есть) будет преобразован в путь к классу, в качестве разделителей используется стандартный разделитель в PHP – ‘\\’.

CLI

• Убрали класс CLI (был только метод CLI::options(), перенесен в Minion_CLI::options()). #3989
• Из класса Kohana убрали статическое свойство $is_cli. Оно теперь не требуется, т.к. вся обработка CLI идет через модуль Minion.

класс Kohana (Kohana_Core)

• Убрали свойство Kohana::$log_errors. Оно все равно не использовалось, при обработке исключений стандартным методом Kohana_Exception::_handler() лог теперь пишется. Осталось не забыть про логирование в своих обработчиках классов HTTP_Exception.
• При инициализации ядра (метод Kohana::init()) добавили проверку на наличие подключенных логов и конфигов в свойствах Kohana::$log и Kohana::$config. Теперь можно спокойно добавлять свои обработчики логов/конфигов ДО вызова Kohana::init() и не бояться, что они пропадут.
• Добавлен метод Kohana::version(), который просто возвращает строку с номером версии фреймворка и ее кодовым именем. Можно использовать для вывода информации где-нибудь в “подвале” сайта мааааленькими буквами.

Request

• Request::factory() поменял перечень принимаемых параметров. Теперь он выглядит следующим образом:

  /**
   *
   * @param   string  $uri              URI of the request
   * @param   array   $client_params    An array of params to pass to the request client
   * @param   bool    $allow_external   Allow external requests? (deprecated in 3.3)
   * @param   array   $injected_routes  An array of routes to use, for testing
   * @return  void|Request
   */
  public static function factory($uri = TRUE, $client_params = array(), $allow_external = TRUE, $injected_routes = array())

  Исключен аргумент $cache, в котором можно было передать объект HTTP_Cache для кеширования запроса, вместо него добавили параметры $client_params и $allow_external (который только появился и уже объявлен deprecated).

  • По названию $client_params можно догадаться, что это параметры, которые будут переданы в Request_Client. На данный момент есть ограничение – будут использованы только те параметры, для которых есть одноименный сеттер в объекте Request_Client. Это ‘cache‘ (передаем объект HTTP_Cache), ‘follow‘ (булевский флаг, который разрешает или запрещает редирект), ‘follow_headers‘ (массив HTTP-заголовков, которые надо передать дальше после редиректа) и ‘strict_redirect‘ (если TRUE, то при 302 редиректе будет сохранен исходный метод HTTP-запроса, как того требует HTTP/1.1 – это поведение по умолчанию).

    Перечень параметров будет дорабатываться и расширяться. Например, сейчас в ветку 3.3/develop добавлены header_callbacks (#4353).

  • Параметр $allow_external позволяет запретить использование Request_Client_External, т.е. все поступающие запросы будут обработаны через Request_Client_Internal, как внутренние.
• Убран метод response(), который позволял получить текущий объект Response.
• Удален метод generate_etag(). В версии 3.2 это был дефолтный способ сгенерировать etag из содержимого Response объекта Request. В 3.3 класс Request уже не содержит свойство $_response, поэтому данный метод доступен только из класса Request.
• Методы query() и post() поддерживают многомерные массивы (применяется Arr::path() вместо Arr::get()). Т.е. теперь можно использовать $request->query('foo.bar'), чтобы получить $_GET['foo']['bar'].

Роутинг

• Фильтры. Одно из самых заметных нововведений. В 3.3 к каждому маршруту можно добавлять условия, влияющие на итоговые параметры маршрута (контроллер, экшен и т.д.). Более того, с помощью фильтров можно даже указать, что данный маршрут не подходит под предложенный URI. Приведу ниже несколько примеров, бессмысленных и беспощадных:

  Используем анонимную функцию, чтобы запретить использование маршрута:

  Route::set('default', '(<controller>(/<action>(/<id>)))')
  	->defaults(array(
  		'controller' => 'Welcome',
  		'action'     => 'index',
  	))->filter(function(Route $route, $params) {
  		if (Kohana::$environment === Kohana::PRODUCTION)
  			return false;
  	});

  Если мы хотим указать, что данный маршрут не подходит, то надо вернуть FALSE из фильтра.

  Вносим изменения в вычисленные параметры маршрута (меняем экшен в зависимости от используемого HTTP-метода):

  Route::set('default', '(<controller>(/<action>(/<id>)))')
  	->defaults(array(
  		'controller' => 'Welcome',
  		'action'     => 'index',
  	))->filter(function(Route $route, $params) {
  		$method = Request::current() ? Request::current()->method() : Arr::get($_SERVER, 'REQUEST_METHOD', HTTP_Request::GET);
  		switch($method)
  		{
  			case HTTP_Request::POST:
  				$params['action'] = 'create';
  				break;
  			case HTTP_Request::PUT:
  				$params['action'] = 'change';
  				break;
  			case HTTP_Request::DELETE:
  				$params['action'] = 'delete';
  				break;
  			default:
  				$params['action'] = 'show';
  		}
   
  		return $params;
  	});

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

• Иногда бывает необходимо объединить кешированные маршруты с уже зарегистрированными в системе. Для этого в метод Route::cache() добавили второй параметр $append. Если он выставлен в TRUE, то загруженные из кеша маршруты будет добавлены к существующим. В 3.2 они их полностью заменяли (впрочем, сейчас это осталось поведением по умолчанию).

Хэлперы

• Исправлена работа метода Arr::get(), теперь он нормально обрабатывает NULL-значения в массиве. #4012
• Добавлен метод Arr::set_path() для установки значения в многомерных массивах. Кроме того, Arr::extract() теперь работает с многомерными массивами (используются пути Arr::path() вместо ключей Arr::get()).
• Arr::merge() теперь объединяет многомерные массивы без замены старого значения на новое. Это в первую очередь полезно при работе с конфигами. Пример можно посмотреть в #3141.
  Date::format_time() теперь принимает в качестве третьего (опционального) параметра идентификатор времЕнной зоны (timezone).
• В хэлпер HTML добавили статическое свойство $strict. Если оно установлено в TRUE (по умолчанию), то сгенерированные элементы HTML будут содержать атрибуты в формате, принятом XHTML. Т.е. не

  <input type="checkbox" checked>

  а

  <input type="checkbox" checked="checked">

• При записи лог-сообщения автоматически будет добавлена отладочная информация (tracelog, имя файла, номер строки и т.д.). А в методе Kohana::log() появился четвертый параметр $additional, в котором может содержаться различная полезная информация для записи в лог. В частности, если в $additional['exception'] сохранить объект Exception, то трейслог будет взят из него.
• Логирование сделано более настраиваемым. В классах-потомках Log_Writer можно переопределить метод format_message(), чтобы установить свой формат текстовых сообщений в логах. Кроме того, добавились статические свойства Log_Writer::$timestamp и Log_Writer::$timezone, позволяющие указать формат даты и временнУю зону для логов.
• Можно указать свой метод для сериализации или кодирования (обфускации) содержимого сессии. Если раньше использовался serialize() и base64_encode(), то теперь они вынесены в методы _serialize()/_unserialize()/_encode()/_decode(). То есть их можно переопределить, если вдруг понадобится.
• Добавился метод Text::user_agent($agent, $value). Точнее, не добавился, а был вынесен из метода Request::user_agent($value). Он вычленял отдельный параметр из пользовательского User_Agent‘а (имя параметра передавалось в $value), а значение User_Agent бралось из Request. Сейчас метод стал более универсальным, в него надо передавать User_Agent явно (например, брать Request::$user_agent). Возможные значения $value:
  • ‘platform’ – имя операционной системы (‘Windows 7′, ‘Windows XP’, ‘FreeBSD’ и т.д.)
  • ‘browser’ – имя семейства браузеров (‘Internet Explorer’, ‘Opera’, ‘Firefox’ и т.д.)
  • ‘mobile’ – имя мобильного клиента (‘iPhone’, ‘Android’, ‘Opera mini’ и т.д.)
  • ‘robot’ – имя бота (‘Googlebot’, ‘Yahoo’, ‘Facebook’ и т.д.)

  Эти настройки берутся из конфиг-файла user_agents.php, и легко могут быть изменены под собственные нужды.

  Примеры использования:
  

  $agent = 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.6.18-1.fc14 Firefox/3.6.18';
  $data = Text::user_agent($agent, 'browser'); // 'Firefox'
  $data = Text::user_agent($agent, array('version', 'mobile')); // array('3.6.18', false)

• В правило Valid::range() добавился 4-й параметр $step (1 по умолчанию). Т.е. теперь можно проверять значение на нахождение в диапазоне значений с произвольным шагом (к примеру, [1,3,5,7,9,11]).

Исключения

• Добавлены классы для HTTP-кодов 300, 301, 302, 303, 304, 305, 307.
• Исключения семейства классов HTTP_Exception теперь могут сообщить, какой Request из “выбросил”. Используйте метод request() для получения этого объекта.
• Исключения HTTP_Exception имеют встроенный валидатор, проверяющий достаточность переданных данных для успешной обработки исключения. Для этого реализован метод check(), в котором мы можем для любого исключения добавить собственную проверку. Вот так, к примеру, проверяются исключения класса HTTP_Exception_Redirect (коды 301-305, 307, 405):

  public function check()
  {
  	if ($this->headers('location') === NULL)
  		throw new Kohana_Exception('A \'location\' must be specified for a redirect');
   
  	return TRUE;
  }

Прочие изменения

• Поправили PHPDOC, особенно в части указания правильных типов возвращаемых объектов.
• Добавлены еще исключения в конфиг inflector.php.

UPD. Пока писал данную статью, вышел второй RC.

Выполнение экшена контроллера

#4377. В версии 3.2 запуском экшенов управлял объект Request (а точнее, метод execute_request() класса Request_Client_Internal). Он запускал before(), затем проверял существование нужного экшена и выполнял его, и под конец запускал метод after(). Концепция удобная, но расположение внутри класса Request_Client_Internal затрудняло внесение изменений в данный процесс. Даже если подкорректировать алгоритм через класс-пустышку, то это затронет абсолютно все внутренние запросы проекта.

В версии 3.3 предложен более удобный способ. Базовый класс Controller имеет метод execute(), внутри которого и расположился описанный выше алгоритм. В результате мы можем легко поменять его под свои нужды, в том числе для отдельной группы контроллеров. Очень удобно. Также можно ловить исключения для целой группы экшенов в одном месте.

Метод execute() должен возвращать объект Response!

HMVC

Переработана идеология работы подзапросов. Теперь они изолированы от родительского запроса. В частности, брошенное исключение или редирект не повлияют на родительский запрос. В любом случае вернется объект класса Response.

В версии 3.2 после брошенного исключения возвращался текст ответа (т.е. строка), а редирект в дочернем подзапросе приводил к остановке выполнения запросов и перенаправлению на новый адрес. Теперь же можно спокойно анализировать результат работы запроса, в частности его статус (с помощью метода status()):

// пример обработки HMVC в 3.3
$response = Request::factory('foo/bar')->execute();
switch ($response->status()) {
    case 404: 
         // обрабатываем 404
         break;
    ...
    case 200:
        // все ок, можно показывать результат
        break;
}

Коды HTTP-ответов

Обработка HTTP-статусов теперь облегчена по сравнению с 3.2, не надо устанавливать и потом анализировать $this->response->status(), достаточно просто выбросить HTTP_Exception:

// отправляем погуглить ;)
throw HTTP_Exception::factory(302, 'http://google.com');

Обработчик исключений сгенерирует Response с соответствующим статусом, заполнит его тело (body) и заголовки (headers) если надо.

HTTP_Exception

Изменения в обработке исключений связаны с изменениями в HMVC. Теперь каждое исключение должно отдавать объект Response в качестве результата работы. Причем механизм различен для семейства исключений HTTP и всех остальных.

Исключения класса HTTP_Exception

В Kohana существует целый ряд исключений для различных HTTP-кодов. Но если в Kohana 3.2 они принципиально ничем не отличались от остальных исключений (разве что для них были заранее заготовлены тексты сообщений в свойстве Response::$messages), то в 3.3 для них можно легко реализовать красивые страницы сообщений. Все, что нужно сделать – написать свой метод get_response() в соответствующем классе.

Например, вот так осуществляется вывод по умолчанию (метод в классе HTTP_Exception):

public function get_response()
{
	return Kohana_Exception::response($this);
}

Это вызов стандартного обработчика, который всегда используется со всеми остальными исключениями (см. ниже). Никто не мешает нам вывести специальную страницу для кода 404 (страница не найдена):

// в классе HTTP_Exception_404
public function get_response()
{
	Kohana_Exception::log($this);
	return Response::factory()
		->status(404)
		->body(View::factory('http/404'));
}

Обработчик очень простой – сообщение об ошибке логируется (стандартный для исключений метод Kohana_Exception::log()), создается объект Response, в который передается статус 404 и специальная вьюшка для отображения страницы Not Found.

Обработчик по умолчанию

Для всех исключений, кроме HTTP_Exception с собственным методом get_response(), будет применен метод Kohana_Exception::response($exception). В нем проводится сбор данных об исключении (код, текст ошибки, трассировка и т.д.) и передается в шаблон для генерации стандартной страницы ошибки (она ничем не отличается от предыдущих версий). Имя используемого шаблона конфигурируется, для этого надо изменить свойство Kohana_Exception::$error_view (по умолчанию ‘kohana/error‘).

Редирект

Выше я уже отметил, что редирект в версии 3.3 не ведет к немедленному прекращению выполнения запроса. Он теперь всего лишь выбрасывает HTTP_Exception с переданным кодом и URI назначения. А тот, в свою очередь, должен вернуть объект Response со статусом и заголовком Location. Если запрос является основным, то объект Response отошлет заголовки, и редирект все же произойдет. А вот HMVC-запросы ломать работу основного не будут, и вместо неожиданных редиректов скромно вернут ответ со статусом 30x.

Помимо общих принципов, изменилось и собственно API для осуществления редиректов. Метод redirect($url = '', $code = 302) переместился из класса Request в классы Controller и HTTP, причем статический (!) метод в контроллере (Controller::redirect()) является оберткой вокруг метода HTTP::redirect().

HTTP-кеширование

В версии 3.2 обработка заголовков HTTP-кеширования велась с помощью метода check_cache($etag = NULL, Request $request = NULL) класса Response. В ветке 3.3 данный метод переместился в класс Controller, и нужды в передаче параметра $request уже нет (передается $this->request).

Для тех, кто не знает, зачем это нужно, предлагаю посмотреть кусок кода из Userguide, метод отвечает за отображение медиафайлов (css, js и т.д.):

if ($file = Kohana::find_file('media/guide', $file, $ext))
{
	// Check if the browser sent an "if-none-match: <etag>" header, and tell if the file hasn't changed
	$this->check_cache(sha1($this->request->uri()).filemtime($file));
 
	// Send the file content as the response
	$this->response->body(file_get_contents($file));
 
	// Set the proper headers to allow caching
	$this->response->headers('content-type',  File::mime_by_ext($ext));
	$this->response->headers('last-modified', date('r', filemtime($file)));
}

Etag вычисляется на основе переданного URI и даты последнего изменения запрашиваемого файла. Если браузер передал заголовок if-none-match с совпавшим идентификатором etag, то до file_get_contents() выполнение не дойдет. От сервера вернется ответ с кодом 304 Not Modified.

Заключение

В данной статье я описал изменения, влияющие на основную задачу ядра – обработку запросов (request flow). Отдельные изменения, затронувшие менее важные задачи (в основном это изменения хэлперов и библиотек) будут описаны в следующей статье.

Подготовка

Для начала необходимо настроить модуль для работы.

• К сожалению, релиз RC1 содержит ссылку не на последнюю версию модуля Minion, поэтому необходимо вручную обновить модуль до последнего коммита (т.е. до HEAD). Это делается командой cd modules/Minion && git pull origin 3.3/develop.
• Разрешаем загрузку модуля Minion в файле bootstrap.php (он там уже по умолчанию есть, но закомментирован).
• Копируем файл minion из MODPATH/minion/ в нужное место (т.е. туда, откуда он будет запускаться планировщиком задач). Можно и не копировать. Затем вносим в него правки, чтобы переменные $application, $modules и $system указывали в правильные места (можно скопировать их из index.php, если вы решили его положить в DOCROOT).

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

./minion --help

Она должна вывести краткую информацию о модуле Minion, а также список доступных для выполнения задач.

Задачи в Minion

Самый простой способ понять этот механизм – создать простейшую задачу. По традиции реализуем вывод фразы “hello world!“:

// файл APPPATH/classes/Task/Welcome.php
<?php defined('SYSPATH') or die('No direct script access.');
 
/**
 * Its a test task class
 *
 * @author biakaveron
 */
class Task_Welcome extends Minion_Task {
 
	/**
	 * Test action
	 *
	 * @param array $params
	 * @return void
	 */
	protected function _execute(array $params)
	{
		echo 'hello world!' . PHP_EOL;
	}
 
}

Вот и все. Если запустить команду ./minion --task=welcome, то в ответ увидим строку “hello world!”.

Каждая задача выполняется в виде отдельного класса-потомка Minion_Task. За выполнение задачи отвечает метод _execute($params).

Передача параметров

В методе _execute() присутствует аргумент $params, который будет содержать все параметры, переданные в задачу через консоль. Все, кроме имени задачи (ключ --task) и специального ключ --help (о нем расскажу позже). Например, ./minion --task=welcome --foo=bar означает передачу параметра ‘foo‘ со значением ‘bar‘.

Имена параметров (в том числе и task) регистрозависимы, поэтому ./minion --Task=welcome и ./minion --tasK=welcome приведут к ошибке. Кроме того, имена задач тоже должны быть в нужном регистре (допускается полностью нижний регистр в имени). Например, ./minion --task=welcome и ./minion --task=Welcome сработают, а ./minion --task=welcomE нет.

Если вы попробовали запустить задачу Welcome с дополнительными параметрами, то должны были получить сообщение об ошибке Kohana. Дело в том, что необходимо для каждой задачи явно описывать допустимые параметры, а также их значения по умолчанию. Таким образом, новая версия задачи Welcome будет выглядеть примерно так:

<?php defined('SYSPATH') or die('No direct script access.');
 
/**
 * Its a test task class
 *
 * @author biakaveron
 */
class Task_Welcome extends Minion_Task {
 
	protected $_options = array(
		// param name => default value
		'foo'   => 'beautiful',
	);
 
	/**
	 * Test action
	 *
	 * @param array $params
	 * @return void
	 */
	protected function _execute(array $params)
	{
		echo 'hello '.$params['foo'].' world!' . PHP_EOL;
	}
 
}

Теперь ./minion --task=Welcome выведет “hello beautiful world” (использовано значение по умолчанию), а ./minion --task=Welcome --foo=great напишет “hello great world“.

Валидация

По умолчанию все переданные параметры проверяются только на их наличие в списке разрешенных. Такое поведение можно легко изменить с помощью метода build_validation(Validation $validation). Он подготавливает объект Validation для дальнейшей проверки параметров. Вот так он выглядит в классе Minion_Task:

public function build_validation(Validation $validation)
{
	// Add a rule to each key making sure it's in the task
	foreach ($validation->as_array() as $key => $value)
	{
		$validation->rule($key, array($this, 'valid_option'), array(':validation', ':field'));
	}
		return $validation;
}

Каждый переданный параметр проверяется с помощью метода valid_option(), который просто ищет имя параметра в списке разрешенных. Если мы захотим ограничить поле foo длиной в 10 символов, то необходимо будет создать в задаче Welcome метод build_validation():

public function build_validation(Validation $validation)
{
	return parent::build_validation($validation)
		->rule('foo', 'max_length', array(10));
}

Не забывайте вернуть объект Validation!

А вот пример для задачи без ограничений по параметрам:

public function build_validation(Validation $validation)
{
	return $validation;
}

Я просто не стал добавлять никаких правил (в том числе и определенных в классе-родителе). Теперь явно указывать параметры задачи в свойстве $_options необязательно.

Справка по задачам

Модуль имеет зарезервированный ключ --help, по которому он отображает справку по задаче (если указана в параметре --task) или по модулю в целом (мы это видели после команды ./minion). Так, вызов ./minion --task=Welcome --help для нашей задачи Welcome вернет такой текст:

Usage
=======
php minion.php --task=welcome [--option1=value1] [--option2=value2]

Details
=======
Author: biakaveron

Description
===========
Its a test task class

Легко понять откуда взялась такая информация – из PHPDOC к классу Task_Welcome. Таким вот образом разработчики Kohana облегчают работу, позволяя разом убивать двух зайцев – документировать исходники и писать man для задач.

Альтернативный запуск задач

Запускать задачи можно и без использования скрипта minion. Любые CLI-команды будут перенаправлены к модулю Minion, поэтому вместо ./minion --task=Welcome можно использовать php index.php --task=Welcome.

Заключение

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

Отмечу, что переход с 3.2 легким не будет. Активно обсуждаемое внедрение стандарта PSR-0 привело к необходимости использовать заглавные буквы в названиях файлов и директорий, а также в именах файлов (сам PHP в общем-то не различает имена классов Foo и foo).

Полезные ссылки:

• Новость на форуме
• Страница RC1 на github
• Закрытые тикеты
• Незакрытые тикеты

Скачать дистрибутив с официальной страницы загрузок пока нельзя. Скачайте zip-архив со страницы на github‘е (кнопка ZIP в верхнем левом углу), либо используйте команды Git:

git clone http://github.com/kohana/kohana.git kohana-v3.3.0-RC1
cd kohana-3.3.0-RC1
git checkout v3.3.0-RC1
git submodule update --init

1. Проект на Github
2. Онлайн-версия.

Напомню, что это НЕ перевод документации, а попытка систематизировать имеющиеся знания о внутренностях фреймворка в несколько вольной форме (хочется избежать сухого языка типичных гайдов). Помимо ядра хочется описать как минимум основные модули (Database, ORM, Auth, Cache).

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

Возможно, среди моих читателей есть кто-то из участников того самого проведенного обучения? Отпишитесь в комментариях о своих впечатлениях. Будет любопытно.

1. Поддержание в актуальном состоянии. Естественно, в случае с PDF это сложнее.
2. Обратная связь с пользователями. Статьи в блоге можно комментировать, это плюс.
3. Версионность. Документацию на текстовых файлах можно выложить на Github и собирать поправки от других пользователей.
4. Удобство пользованием. Что ни говори, а PDF-файл можно распечатать, его удобно читать с различных ридеров и т.д. В блоге больше лишних (отвлекающих) элементов.

Продолжать можно долго. А что думаете вы? Помимо формата, принимаются предложения по содержанию учебника.