Стал доступен для скачивания и тестирования первый Release Candidate новой ветки 3.2.x фреймворка Kohana. Разработчики обещают, что серьезных изменений намного меньше, чем было в 3.1. Вот основные:
- Изменена работа с конфигами. Теперь есть драйверы только на чтение (
Config_Reader) и с возможностью записи (Config_Writer). Если говорить про смену API, то придется вместоKohana::config($path)использоватьKohana::$config->load($path). Интересно, что мешало сохранить старый механизм, он ведь короче и удобнее. - Сделана более удобной работа с внешними запросами (
Request_Client_External). Раньше способ выполнения запроса зависел от наличия подключенного расширения PHP (Curl/PECL_HTTP), вручную его нельзя было выбрать. Сейчас же можно указать дефолтный драйвер разом для всех запросов, либо менять его для конкретного запроса:
// Все внешние запросы должны использовать PECL HTTP Request_Client_External::$client = 'Request_Client_HTTP'; // Используем стандартные средства PHP для данного конкретного запроса $response = Request::factory('http://kohanaframework.org') ->client(new Request_Client_Stream) ->execute();
В общем-то типы запросов остались те же:
Request_Client_Curl(способ по умолчанию, требует Curl),Request_Client_HTTP(требует PECL_HTTP) иRequest_Client_Stream(ничего не требует, но это самый медленный способ). - Немного изменилось кэширование запросов. Как мы знаем, раньше для кэширования надо было передавать в запрос объект
Cache:$request = Request::factory('foo/bar', Cache::instance('memcache'));
Теперь имеется специальный объект для работы с
HTTP-кэшированием:$request = Request::factory('foo/bar', HTTP_Cache::factory('memcache'));
Правда, подключать модуль
Cacheвсе равно требуется.
Полезные ссылки:
- Обсуждение на форуме
- Метка git для данного RC
- Ветка 3.2/develop на Github (текущая разработка ветки 3.2)
- Небольшая инструкция по переходу на 3.2 (очень сырая, да и переход там с 3.0, так что перемешаны изменения из 3.1 и 3.2).
- Полный перечень изменений (точнее, отработанных тикетов).
Когда немного поиграюсь с этой версией, возможно дополню список новшеств (или создам более подробную статью, если их будет много).
Loading ...
С нетерпением жду стать!!! Спасибо что поддерживаете блог в актуальном состоянии.
Хоть ОРМ и Валидацию не тронули?
Пока вроде нет ))
Они добавили возможность хранить конфиги в базе данных.
Интересно. Странно, что это новая версия, по изменениям больше на минорное обновление 3.1,х версии похоже.
@Big_Shark
Сами по себе DB-конфиги и так были. Добавилась возможность сохранять их в БД (т.е. редактировать), о чем я и написал в новости.
@e-FreeZe
Любые изменения API выносятся в следующую ветку. Потому и 3.2. А в 3.1 будут более мелкие дополнения, по сути багфиксы.
Я думал, что в 3.2 войдут более существенные изменения, например, MPTT добавят к ORM. Тем более что переделывать много не надо — для себя портировал еще с 2 версии и вроде работает и в 3.1
ORM ведь отдельный модуль, и может (теоретически) развиваться отдельно от ядра.
Другой вопрос: для чего развивать версию 3.2 и тратить одновременно время на: v3.0.12 и
v3.1.4 и
v3.2.0 и
v3.3.0
.. источник http://dev.kohanaframework.org/projects/kohana3/roadmap
Дмитрий, ИМХО тут на самом деле не настолько все сложно. Багфиксы как правило можно добавлять сразу ко всем сопровождаемым веткам. Новые фичи — во все разрабатываемые. Ну и т.д. Как по мне, основная проблема в документации, ну еще возможно отставание модулей от веток (не всегда разработчики хотят/могут вести сразу несколько параллельных ветвей для разных версий ядра).
Еще убрали параметры у метода url, в Request, т.е. подобное уже не работает
Request::current()->url(array(‘action’=>’personal_save’)))
Как теперь делать правильно подобное, не очень понятно.
@xbagir
Через
(https://github.com/kohana/core/blob/3.2%2Fmaster/classes/kohana/route.php#L190)
@biakaveron
Спасибр. Ого, теперь чтобы просто изменить в урле action, простенькая запись:
Request::current()->url(array(‘action’=>’personal_save’)))
Превращается в монстра:
Request::current()->route()->url(‘default’, array(‘controller’=> Request::current()->controller(), ‘action’=>’personal_save’)));
Пагинатор отвалился из-за того, что использует старый метод загрузки конфигов
Kohana::config
хотел добавить issue, а его уже добавили до меня:
http://dev.kohanaframework.org/issues/4128
Jeremy Bush , пишет что пагинатор не поддерживается с версии 3.1. А кто теперь его поддерживает? Кто-нибудь владеет информацией?
@botaniq
Вы наверное не так поняли. Пагинатор не включили в дефолтную комплектацию фреймворка (как и модуль OAuth) в связи с отсутствием полного покрытия юнит-тестами. Оба этих модуля развиваются и могут быть использованы в проектах.
@biakaveron
А пагинатор что-то не фиксят уже давно. Текущая версия, действительно, не рабочая для 3.2. Я у себя ручками пофиксил, чтобы хоть как-то работало. Бранча на 3.2 версию там нету.
И планируется ли?
На dev.kohana что-то ни намека.
@xbagir
Навскидку могу посоветовать разве что https://github.com/kiddivouchers/kohana_pagination/tree/refactor%2Fkohana3.2. На самом деле никто не мешает сделать тикет с запросом на новую ветку. Ну или форкнуть и развивать дальше. В принципе, нам для KW пагинатор нужен, может и у себя развернем копию.
@biakaveron
Это здорово — пригодится. Я пофиксил и kohana-static-files и пагинатор. Нужно только pull сделать к вам. Надо разобраться как, руки не доходят — работы валом. Завтра создам тему на англоязычной ветке, узнаю почему запилили пагинатор вообще.
Судя по всему botaniq прав, его отказались развивать.
Запостил тему, кому интересно
http://forum.kohanaframework.org/discussion/9389/pagination-isnt-supported-since-3.1-s-kohana-3.2
Сами по себе DB-конфиги и так были. Добавилась возможность сохранять их в БД (т.е. редактировать), о чем я и написал в новости.
@biakaveron
Редактирование конфигов в бд появилось еще в версии 3.1
Вижу в вашем блоге много записей про ORM, собственно именно отсюда я и узнал о Jelly и Sprig. Подскажите, а как обстоят дела с ORM в Kohana 3.2? Насколько я знаю Jelly еще не обновился (в 3.1 я использовал форк от creatoro), Sprig — недоступен вообще, как я понимаю автор работает над Hive, который пока в состоянии альфы. Выходит для боевых проектов ничего нет?
Стандартный ОРМ мне не нравится лишь тем, что каждый запрос к базе сопровождается лишним запросом структуры БД. Может быть есть путь прописать структуру в коде и избавится от этого?
@soar
Подозреваю, что для 3.2 в скором времени появится своя ветка Jelly, т.к. уж очень популярный это проект.
По поводу кэширования структуры в ORM почитайте здесь.
Спасибо