satis.001

Мы все любим Composer. Он значительно изменил способ как мы создаем PHP приложения, основываясь на маленьких и повторно используемых компонентах, но это создает новые проблемы, особенно когда мы имеем единую точку отказа (SPO).

Читать далее

kohana doctrine

В виду того, что проект Kohana вообще закрылся и версию 3.4 c namespace мы наверное никогда не увидим следует вывод – не стоит начинать на ней новые проекты. Но что делать, если приходится поддерживать старые. Не пользоваться же ORM Kohana, ее знание и знание ее особенностей уже ни кому не нужны. Значит надо подключить Doctrine.

Читать далее

В новом (относительно) Bootstrap 3 отсутствует возможность по умолчанию для выпадающего меню в навигациии задавать уровень вложенности более чем 2. Т.е. невозможно построить навигацию с бесконечным выпадающим меню используя возможности Bootstrap 3 по умолчанию. Для добавления такой нужной возможности существует следующее решение.

Читать далее

В данном посте я хочу сохранить обсуждение и решение проблемы с офф форума Kohana. Проблему обозначаю в первой цитате, решение с подсказки сообщества (использовать коллбеки) во второй, т.е. сам код. Работает для kohana 3.2, для 3.3 надо править, чего я не сделал в виду не надобности. У меня проект на 3.2. :)

Читать далее

В данный момент разрабатываю проект на Kohana. В этом проекте не малую роль играют задания выполняемые через cron. Еще не имея опыта работы с cron и Kohana я думал, что скрипты можно вызывать напрямую, а в контроллере делать проверку Kohana::$is_cli для определения вызова cli. Но как выяснилось существует модуль с версии 3.0, который эволюционировал и в 3.3 стал частью поставки Kohana по умолчанию.
Проблема в том, что Kohana 3.3 внесла некоторые изменения в свой autoload, которые несомненно более удобны. Теперь не обязательно писать классы с заглавной только первой буквой и не обязательно именовать файлы и папки в нижнем регистре. Теперь можно писать так Kohana_CLI, Class_InvalidTask и еще так InvalidTask.php.

Для прикрутки module Minion сначала я хотел было воспользоваться версией для 3.2, которая была загружена Zeelot3k в теги модуля на git. Но там оказалась поделка из более ранней 3.1. В ней используется bash скрипт для вызова index.php с параметрами, когда как в 3.3 minion просто обертка для модуля. Выложенное решение для 3.2 по моему не рабочее, по крайне мере я так и не смог запустить свой task.

После я копировал модуль с 3.3 версии.
Для запуска модуля необходимо переименовать все файлы в директории minion в нижний регистр, включая папки. так же исправить имена файлов и классов по правилам именования Kohana 3.2, т.е. Kohana_CLI на Kohana_Cli и InvalidTask в Invalidtask.
Далее подключить модуль как обычно в Kohana::modules() и исправить index.php в конце на следующий код

И все, должно работать. Создаем в папке /classes/task файл welcome.php с кодом

Далее вызываем.

Темы с вопросами о minion с официального форума:
1
2
3

Так же в решении вопроса мне помог блог участника сообщества biakaveron.
У него можно почитать про модуль подробнее.

GIT REPO: https://github.com/seyfer/minion

UPD: 2014-11-28

Сейчас я пользуюсь стандартным minion для версии 3.2, т.к. у меня возникли некоторые проблемы с совместимостью с другими модулями.
Поэтому я описал пакет вот так

И подключил его в require, а мой портированный с 3.3 удалил. Проект на 3.2. и отлично все работает.

Сначала перечисляю сущности.
sуstems – некие системы.
preferences – некоторые настройки, сокращенно pref

pref имеет разные типы, например настройки кеша (cache) и тамаута (timeout). Таким образом pref можно записывать в одну таблицу с полями id, value, type или в две разные таблицы – prefcache и preftimeout с той же структурой. Идем дальше.

Поля таблицы system – id, name. Осуществляется связь многие ко многим через таблицу prefs_systems с полями: id_system, id_pref, type (можно вынести сюда в случае отдельных таблиц prefcache и preftimeout.

И вот зачем две таблицы pref, я хочу на каждую делать свой ORM, т.е. есть базовый ORM_Pref extends ORM и от него наследуются ORM_Prefcache и ORM_Preftimeot. Каждый работает со своей таблицей, а общие настройки в базовом классе.

В этом случае в каждой ORM прописываются связи $_has_many. В случае ORM pref все очевидно, по одной записи связей $_has_many к ORM_System. В случае с описанием ORM_System получается такая конструкция (додумался пока писал).

Вопросы:

  1. Нормально ли я придумал структуру?
  2. Могу ли я базовый класс ORM_Pref объявить абстрактным (т.к. у него нет привязанной таблицы и его не надо создавать) ?
  3. Можно ли как-то улучшить мою структуру? Если все выше правильно, то при добавления нового типа настроек я должен буду прописать связь в ORM_System, это не удобно.

UPD. 02.04.2014

Спустя полтора года мой пост выше кажется мне уже простым вопросом новичка. Решил добавить сюда еще решение по ORM

Получение свойства ORM сразу с UNCOMPRESS.

Проблема: Можно ли как-то через ORM извлекать данные, которые были записаны через COMPRESS () в mysql в BLOB?

В кохановском ОРМ такого нет. Приходится писать функции в ORM типа

Задачу решает, но было бы приятнее просто указать в каких-то правилах как извлекать столбец, как фильтры после извлечения, только эти во время.

Решение нашел коллега. В нужной ORM модели надо переопределить

В данном случае поля request и result сжаты, извлекаются под псевдонимами с распаковкой и будут доступны $model->requestUncompress, например.