Иногда в голове мелькает мысль, «а ведь это неочевидно/полезно/любопытно«, но целый пост на эту тему писать бессмысленно. Поэтому буду периодически публиковать такие вот «выхлопы» с накопившимися заметками. Ниже — первая пачка из данной серии.
- «Ленивая загрузка» в ORM позволяет делать дополнительную фильтрацию после обращения к «множественным» свойствам модели. Например, так мы отфильтруем неподтвержденные комментарии к записи в блоге, а также отберем только второй десяток из них:
$comments = ORM::factory('blog', 1)->comments ->where('is_confirmed', '=', 1) ->limit(10) ->offset(10) ->find_all();
На все это уйдет только один запрос, т.к. он теперь формируется только после явного вызова
find_all()
. - Так как библиотеки Input теперь нет, очищать данные от XSS придется самостоятельно (
Security::xss_clean()
вам в руки, можно добавить как фильтр в Validate). Автоматически Ko3 лишь убирает лишние слэши (т.е. можем не думать о magic_quote_qpc) и все переводы строк приводит к единому виду («\n«). Если надо обратиться к глобальной переменной, но есть сомнения в ее существовании, можно использовать методarr::get()
, он поддерживает установку значения по умолчанию. Например, так:arr::get($_POST, 'text', '');
- Список подключенных модулей может быть откорректирован в любой точке приложения. Метод
Kohana::modules($modules)
заново подключит все модули, указанные в массиве$modules
. При этом ранее подключенные модули будут отброшены. Если вызвать метод без параметров, он вернет текущий список активных модулей. Таким образом, можно на лету подключить модуль X:
Kohana::modules(arr::merge(Kohana::modules(), array('x' => MODPATH.'x')))
. Пути для автозагрузки классов будут заново просчитаны, так что можно добиться изменения порядка активации модулей в списке (это играет роль при работе каскадной файловой системы Kohana).Насчет возможной двойной отработки файлов init.php не волнуйтесь — они подгружаются через
require_once()
. Тем не менее, сама по себе функция довольно затратная, не стоит ее вызывать бездумно. - Можно кэшировать отдельные участки страницы с помощью класса Fragment:
if ( ! Fragment::load('some_page', 100)) { echo View::factory('some_page_view'); Fragment::save(); }
В данном случае мы проверяем наличие кэшированной версии по ключу ‘some_page‘, устанавливая срок актуальности (lifetime) в 100 секунд. Если фрагмент не найден, надо его отобразить и сразу добавить в кэш (метод
Fragment::save()
). Если же в кэше есть нужный нам кусок страницы, он отобразится автоматически. По умолчанию lifetime ставится на 30 секунд. Ах да, кэш — файловый, пока что нет библиотеки Cache а-ля Kohana v2.3.4. - Запросы на добавление записей (INSERT) возвращают массив (последний_сгенерированный_id, количество_вставленных_записей), а для редактирования (UPDATE) и удаления (DELETE) — только количество измененных/удаленных записей.
> пока что нет библиотеки Cache а-ля Kohana v2.3.4
Как это нет?
Гм… все время про этот проект забываю. Надо все же потестить.
Попутно позволю себе замечание:
Меня несколько смущает оставшаяся со времен 2.3.4 структура классов (папка driver, отдельный класс driver). Посмотрите на модули Image или Auth, там данный лишний слой убран.
Пожалуйста подскажите, есть ли где-нибудь документ по coding style и name convention для KO3. Никак не могу понять, почему Security::xss_clean, но arr::get? Ведь и то, и другое — хелперы.
Гм… Судя по всему, я немного ввел Вас в заблуждение. Сейчас в Ko3 все классы начинаются с большой буквы, т.е. Arr::get(). Видимо, написание arr (как часто используемого класса) с маленькой осталось от версии 2.3.x. А в целом coding style остался прежним.
А еще в КО3 изменена таблица сессий (название полей отличается от версии 2.х, о чем и писал http://forum.kohanaphp.com/comments.php?DiscussionID=3657&page=1#Item_1
Ну, если говорить об изменениях в Ko3 по сравнению с Ko2, можно подглядывать и отписываться сюда.