Так как первая цель практически любого человека, осваивающего фреймворк — создание собственной небольшой CMS, то потихоньку ей и занимаюсь. Одно из условий — модульная структура: я хочу создать несколько функциональных блоков, объединенных неким ядром CMS, например с единой системой аутентификации. Каждый блок должен быть самостоятельным, т.е. зависеть только от ядра (чтобы всегда можно было подключить модуль «блог» без использования «форума»).
Значит должна быть некая единая настройка для подключения к БД (собственно говоря, это файл application/config/database.php) и дополнительные параметры для отдельных модулей. Уж не знаю, надо ли это, но у меня лично есть небольшой бзик — каждый модуль должен иметь возможность собственного именования таблиц, по сути — нужны префиксы. Поэтому я обратил внимание на один из параметров конфигурационного файла database.php, а именно — на $config['connection']['table_prefix']. Он позволяет установить префикс для используемых данным подключением таблиц. Однако менять его в application не подходит, т.к. префиксы будут использованы для всех таблиц, а нам надо разделение по модулям.
Модульные настройки доступа к БД
Тут вспоминается наличие каскадной файловой системы в Kohana — мы ведь можем создать собственные конфигурационные файлы в модуле, и если в application он не будет перекрыт, то система его считает. Поэтому появилось желание определить префиксы именно таким образом. Но увы! Мы ведь не можем заранее предугадать все прочие настройки приложения (хост, логин, пароль и т.д.). В идеале конфигурационный файл выглядел бы так:
// modules/forum/config/database.php $config['forum'] = array ( 'table_prefix' => 'forum_', ); |
Т.е. просто опускаем все ненужное (то, что будет совпадать с default‘ом), указываем только необходимое. К сожалению, это не работает. С другой стороны, таким образом мы бы упустили возможное использование префиксов default‘ными настройками, что тоже not good.
Составляем конфигурацию ручками
Конечно, нам все равно необходимо было бы как-то указывать используемое название профиля подключения к БД, поэтому в код моделей лезть придется. И тут возникает мысль — а не подправить ли нам префикс в конструкторе, ДО вызова parent::__construct()? Почему до — ведь подключение к БД обычно создается именно в родительском конструкторе, как например это сделано в ORM‘е. А если создать объект $this->db (напомню, изначально в нем хранится только строка с названием профиля БД), то он заново создан не будет. Соответственно как это все будет выглядеть:
// modules/forum/config/database.php $config['forum'] = array ( 'table_prefix' => 'forum_', 'use_default_prefix' => TRUE, ); // modules/forum/models/forum.php class Forum_Model extends ORM { protected $has_many = array('topics'); public function __construct($id = NULL) { $config = Kohana::config('database.'.$this->db); $newconfig = arr::overwrite($config, Kohana::config('database.forum')); if (Kohana::config('database.forum.use_default_prefix')===TRUE) { $newconfig['table_prefix'] = $config['table_prefix'].Kohana::config('database.forum.table_prefix'); } $this->db = new Database($newconfig); parent::__construct($id); } } |
Таким макаром мы с помощью Kohana::config() составляем массив на основе текущей и требуемой конфигурации БД, который позже «скармливаем» конструктору. Параметр use_default_prefix нам необходим для того, чтобы учитывать используемый в конфигурации приложения префикс таблиц. Ну и напоследок, дабы не писать это в каждом конструкторе, создадим свою версию ORM для данного модуля:
// modules/forum/libraries/Forum_ORM.php class Forum_ORM extends ORM { public function __construct($id = NULL) { $config = Kohana::config('database.'.$this->db); $newconfig = arr::overwrite($config, Kohana::config('database.forum')); if (Kohana::config('database.forum.use_default_prefix')===TRUE) { $newconfig['table_prefix'] = $config['table_prefix'].Kohana::config('database.forum.table_prefix'); } $this->db = new Database($newconfig); parent::__construct($id); } } |
Соответственно все модели модуля «forum» должны быть унаследованы от класса Forum_ORM. Не знаю, будет ли данный вариант использоваться мной как итоговое решение, время покажет. По крайней мере на форуме мне в свое время ничего посоветовать не смогли.
PS. Данные мысли открывают новую рубрику сайта — «Пишем CMS«. В отличие от учебника (где публикуются скорее общие алгоритмы, чем практические задачи) тут я буду писать проблемы и решения на пути к созданию собственной ЦМСки.
Поищите на форуме, там была уже попытка создать CMS на основе kohanaphp. Hanami кажется. Я не следил за продвижением этой разработки, но сразу мне как-то показалось, что парни пошли не в том направлении. А было б неплохо создать репозиторий где-то на гуглокоде и писать вместе.
Конечно, мне было интересно посмотреть и hanami, и s7ncms, и другие проекты. Вообще натыкаться на такие же грабли не так полезно, как научиться их обходить
А исходники я буду выкладывать, как только что-то начнет вырисовываться
авторизацию будете свою писать или воспользуетесь модулем Auth?
Auth устраивает на 90%, надо только некоторые моменты допиливать… Хотя по ходу пьесы все еще может поменяться.