Например: Программист
0,2
рейтинг
12 августа 2009 в 09:47

Разработка → Что нам готовит Kohana 3

Как-то так получилось, что примерно месяц я не следил за разработкой этого замечательного фреймворка. Наблюдение за скоростью разработки версии 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
Александр Карпинский @homm
карма
88,8
рейтинг 0,2
Например: Программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (52)

  • +6
    Молодцы ребята из Kohana, я все ждал что Codeigniter оживет, но там только вялотекущая борьба за 1.7.2, и видимо ничего нового не намечается. Так что буду переходить на Kohana.
    • 0
      вам шашечки или ехать?
  • 0
    Вот теперь кохана становится самостоятельным фремворком, а не «чуть получше кодигнитера».
    • 0
      Да, причем получается такой очень приятный микс из лучших приёмов программирования в других фреймворках. Судя по этой статье — большое будущее ожидает кохану, если разработка пойдёт теми же темпами.
  • +1
    Действительно много замечательных изменений. Надеюсь, что документация будет тоже на уровне — значительно упростится ознакомление и работа с новой версией.
  • 0
    Если я не ошибаюсь, Shadowhand заикался о начале разработки версии 3.2, по-моему не лучшая стратегия: 3.0 еще не выпущена, а уже задумались о следующих принципиальных изменениях.
    Фреймворк отличный, но хочется надеяться, что версия 3.0.х проживет хотя бы год, иначе опять придется бросать проекты без обратной совместимости…
  • +1
    Теперь Kohana стал больше похож на Zend FrameWork. К примеру в части с разбивкой по файлам (Kohana_Database_Query_Builder) и в роутерах.
  • +1
    КакеПхп начинает отдыхать, на сцене два новых борца Юии и Кохана
  • 0
    ждем, ждем.

    Доки главное чтобы не забыли.
  • 0
    Когда я сел за Кохану я долго и громко матерился. Чехарда с _Core, убивающая автокомплит раздражала. Хотел сделать ->orderby('md5(id)', 'asc'), фиг там. Кроме rand() ничего нельзя совать. Пагинатор просто ужасает. Видите ли надо указывать номер сегмента со страницей. Ужас, я так понимаю, что url парсится как строка, а не как пары «переменная => значение'.
    Документацию давно пора расширять. Надо выкинуть из мануалов доки про Formation и Forge, если они не работают с современными версиями.

    Думал я закинуть нафиг этот фреймворк, но версия 3 дает робкие надежды, что все будет хорошо
  • 0
    Толи описано плохо(в данной статье), толи я уставший, не понял какие преимущества у нового роутинга. Контроллер, экшн и парамтеры теперь могут быть в произвольном порядке? Сохранится ли возможность роутить по старому?

    > кроме mysql и pdo). Но не волнуйтесь, все это можно будет скачать дополнительными пакетами.

    Месяц назад, читал, что «мы не используем ничего кроме mysql», так что закачаешь нужный драйвер можно будет, если кто-то напишет и выложит.
    • +1
      Главное, чтобы не в ущерб производительности, все эти нововведения…
    • 0
      Толи описано плохо(в данной статье), толи я уставший, не понял какие преимущества у нового роутинга.
      Описано плохо :) потому что я сам еще в новом роутинге не сильно разбирался.
      Сохранится ли возможность роутить по старому?
      Единственное правило, заданное по умолчанию и которое я привел в статье как раз и роутит по старому.
      • 0
        Всё таки вариант хранить пути в статичном конфиге, мне нравился больше, чем вызов вот таких вот функций. Но хотя рано говорить надо смотреть, месяц назад на КОЗе не на что смотреть было, кроме новой иерархии, да конфигов, кстати про них забыл.
  • 0
    • 0
      Всё равно, там ничего интересного не было, всё что было переведено и так спокойно читалось :)
  • –3
    приятно звучит для украинцев название :) (кохана — любимая)
    • 0
      Простите, но это баян :)
      • 0
        в первый раз услышал :)
        на php никогда не работал)
    • –2
      Ko3'a моя любимая :)
    • +2
      йопт ну сколько можно?
  • 0
    Route::set('default', '((/(/)))')
    ->defaults(array(
    'controller' => 'welcome',
    'action' => 'index',
    ));

    В чём смысл указания дефолтного контроллера и действия, если id всё равно обязательный?
    • +1
      Route::set('default', '(<controller>(/<action>(/<id>)))')
          ->defaults(array(
              'controller' => 'welcome',
              'action'     => 'index',
          ));
      
      • +2
        Повторюсь еще раз, что не разбирался в роутах, но мне почему-то кажется, что в скобках записывается необязательная часть.

        Из этого предположения, можно сделать вывод, что запись "(<controller>(/<action>/<id>))" означала бы, что ничто не обязательно, но можно указать контроллер. А если указан action, то становится обязательным и id (т.к. id не окружен своими собственными скобками необязательности). Но это все домыслы.
        • 0
          угу, единственно логичное объяснение. мерси.
  • +1
    Вот чего не хватает этому фреймворку, так это документации. К сожалению.
    • 0
      да уже сегодня можно с уверенностью сказать, что почти все фреймворки похожи друг на друга чуть менее чем полностью. нет правда :-)
      • 0
        Ну учитывая, то что задача php фреймворков одна, и практически везде используется MVC, было бы странным если бы они сильно отличались.
        А вобще не согласен, фреймворки имеют значительные различия, чтобы бросаться фразами «чуть менее чем полностью», если я не прав приведите пример таких нереальных похожестей.
        • 0
          ну вот недавно у меня был первый опыт работы с kohana 2.x
          всю дорогу не покидало чувство дежа-вю.
          • 0
            Дай угадаю, до этого был код игнитер?
            • +1
              вот уж совсем за дурака меня принимать не нужно :-(
              • 0
                Ну а на что ещё так сильно похожа кохана как не на CI.
                • 0
                  на ряд фреймворков понемножку. при работе с ним постоянно возникает чувство, что где-то это уже было, возможно, это очень субъективно.
  • +1
    Буквально две недели начал использовать ko3 с doctrine. Пока только самые лучшие впечатления от фреймворка.
  • 0
    Ой, я когда с ним разбирался, строчки для генерации Core классов в ядре Kohana
    // Transparent class extensions are handled using eval. This is
    // a disgusting hack, but it gets the job done.
    eval($extension);

    Просто убила… До этого долго удивлялся почему автодополнение не работает… Слава богу что это поправят…
    То, что автоконструктор SQL доработали — тоже весьма радует!
    Очень жду релиза!
    • 0
      Такие конструкторы запросов, иногда заставляют меня задуматься, а не проще ли пользоваться SQL диалектом при условии, что вероятность смены «драйвера» стремится к нулю.
      • +1
        конструкторы запросов позволяет собирать запросы, передавая объект конструктора в различные билдеры-критерии, каждый из которых добавляет к запросу что-то своё.
        • 0
          Возможно моё мнение сформировалось, из-за излишнего сложного класса, для построения строки. И из-за того, что за редким исключением билдеры у меня не в виде цепочки.
          В кохана 2, билдер никогда не нравился, особенно из-за своих ограничений.
          • 0
            а они и не должны быть в виде цепочки (в нормальных реализациях билдеров)

            $criteria = new criteria('table');

            advanced_add_pager_function($criteria);

            $select = new select($criteria);
            • 0
              ну это я ессна не про кохану говорю, а вообще «как бывает».
            • 0
              Ну судя по возможностям, здесь задачи билдера не ограничиваются постройкой строки.
  • +2
    Документацию бы ему ещё и плотное сообщество…
    • +1
      совместными усилиями…
    • +1
      Сообщество офигенное, зря Вы так. Документацию Shadowhand обещал не хуже, чем у Yii о прочих «оформленных» конкурентов ;)
      • 0
        Обещал, сделал и есть сейчас — три разные вещи.
      • 0
        Уже год обещают :)
  • +2
    Эээх, о главном забыли написать — HMVC безо всяких лишних усилий! В любом месте приложения можно написать что-то вроде $result = Request::factory('some/url')->execute()->$response; — и получим результат работы скрипта как если бы вызывали его вручную.
    При этом первоначальный объект Request (который инициировал работу приложения) доступен через Request::instance();
  • –1
    — Первое, что бы хотелось отметить, совместимости с версией 2.3 не будет

    Дальше читать не стал. Вот поэтому я и пользуюсь CodeIgniter'ом, а не его многочисленными клонами.
    • +1
      А надо было дочитать. Вторая ветка будет продолжена релизом 2.4
      • 0
        Будет куча несовместимых веток? Здорово!
        Мне это чем то напомнило так толком и не родившийся Pligg.
        Нет уж, я буду хранить верность своему фреймворку.
        • 0
          Два — это куча? Для улучшения существующих проектов используйте 2.4, для новых — 3.0. В чем проблема-то? :) Или лучше не вносить ничего нового, тормозить развитие из-за проблем обратной совместимости? Если Ваш ответ «да», то оставайтесь на CI, ничего не поделать.
        • 0
          Даешь поддержку PHP 3!

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