Pull to refresh

Что нам готовит Kohana 3

Reading time 4 min
Views 2.3K
Как-то так получилось, что примерно месяц я не следил за разработкой этого замечательного фреймворка. Наблюдение за скоростью разработки версии 2.4 вызывало тоску. Но вчера я заглянул на сайт и ахнул. Оказывается, разработчики, не дождавшись готовности версии 2.4, успели уже выпустить целых 2 релиз кандидата версии 3. Глянул я в исходные тексты, немного почитал форум и стало мне так радостно на душе от грядущих изменений, что я решил не дожидаться 09.09.09 или ранее и поделиться радостью.
Замечание не по теме: Кстати, я против того чтобы версии, которые явно еще планируется дорабатывать называть RC, ведь ясно что они не станут release, какой тут может быть candidate.

Первое, что бы хотелось отметить, совместимости с версией 2.3 не будет, если вы захотите перенести с неё проект, вам придется внести большое количество изменений, в основном в имена классов, но скорее всего этим дело не ограничится.

Новые особенности движка


Иерархия файловой системы

Организация файловой системы полностью пересмотрена, а вместе с ней изменились и правила именования классов. Система также осталась многослойная, где каждый следующий слой перекрывает файлы предыдущего (картинка). Изменилось вот что: больше нет явно выраженного деления на хелперы, модели, контроллеры и чего ещё. Все классы теперь хранятся в папке classes. Больше ни нам, ни движку не нужно применять странные правила именования для определения того, что перед нами, за всеми классами система ходит в один и тот-же каталог. Соответственно изменились правила именования самих классов, название должно состоять из всех подкаталогов каталога classes, в которых находится файл и имени самого файла. Например, класс Database_Query_Builder будет лежать в файле /classes/database/query/builder.php. Таким образом, если мы складываем все контроллеры в папку controller, мы автоматически получаем правило именования контроллеров: они должны начинаться на префикс «Controller_».

Расширение базового функционала системы

То, о чем говорили раньше, как же так strict php5 OOP framework генерирует классы на лету через eval, больше нет. Поясняю, кохана ветки 2.0 позволяла расширять базовые классы, наследуясь от мифических классов с постфиксом _Core. Эти самые _Core и были настоящими классами, а классы с именами без _Core, если они не были определены пользователем, генерировались на лету. Больше такого безобразия не происходит и все расширение происходит намного проще: все файлы системы представляют из себя пустые классы, отнаследованные от классов «Kohana_%classname%». Например, вот определение того же Database_Query_Builder:

abstract class Database_Query_Builder extends Kohana_Database_Query_Builder {}


Базовые же классы, как уже видно из названия, просто лежат в папке classes/kohana. Таким образом сильно упрощается механизм автолоада, больше ему не нужно различать типы классов и генерировать чтото на лету, все классы проименованны в рамках одной концепции. Кроме того, больше не понадобятся костыли для автокомплита в NetBeans или Eclipse.

Фреймворк «попилили»

Из папки system решили выкинуть все лишнее. При чем, кое что выкинули в отдельные модули, которые идут в одном дистрибутиве (например, database и orm), а кое чего нет и там (не нашлось места captcha и всем драйверам баз данных, кроме mysql и pdo). Но не волнуйтесь, все это можно будет скачать дополнительными пакетами.

Полный контроль над процессом загрузки

Файл bootstrap.php, который отвечает за сбор кусков системы в рабочий механизм, перекочевал из системы в application. А это значит, что мы теперь можем вмешаться в любой аспект работы системы еще до его загрузки. В частности, мы можем добавить свои адаптеры логов и конфигов, которые будут работать, например с базой данных или с xml. Сюда же перекочевали многие настройки, которые раньше были в отдельных конфигах. Например, используемые модули, роутинг. Кстати, роутинг заслуживает отдельного упоминания. Говорят, он стал похож на RoR, но я RoR не видел, так что смотрите сами:
Route::set('default', '(<controller>(/<action>(/<id>)))')
    ->defaults(array(
        'controller' => 'welcome',
        'action'     => 'index',
    ));


Изменения в слое баз данных

Это, на мой взгляд самая сочная часть. Слой базы данных был полностью заменен, и, надо сказать очень не зря. Если раньше query builder охватывал процентов 70 от всех нужных запросов, то теперь эта цифра стремится к 99. Судите сами, с помошью нового query builder, теперь можно:
  • Использовать произвольные функции для полей, не только заданные разработчиками
  • Использовать скобки в выражении where
  • Задавать несколько условий для join, причем они больше не обязаны быть полями связываемых таблиц, можно задать значения или функциям от полей.
  • Использовать вообще произвольные выражения, если функционала не хватило с помошью DB::expr()
  • Использовать подзапросы!
  • Делать вставки из выборок (INSERT … SELECT)

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

Изменения в слое ORM

Может быть я что-то упускаю, но как я понял, изменения в ORM не столь глобальны. Наиболее значительное изменение — ленивая загрузка, теперь запрос к базе данных делается только когда это необходимо. Это позволяет, например, избежать двух запросов при удалении:
ORM::factory('user', 'homm86@gmail.com')->delete();


Кроме того

Коснулись изменения и другие аспекты работы движка, например интернационализация, введен механизм сообщений, появился REST-контроллер, системы логирования и конфигов получили возможность работать с разными адаптерами, не только с файлами на диске, добавили view fragment caching, но пусть обо всем этом расскажет кто-то другой, или я, но после выхода :)

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

Ситуация с версиями 2.4 и 3.0
Tags:
Hubs:
+21
Comments 52
Comments Comments 52

Articles