Пару лет назад, когда только появился CodeIgniter 2.0, многие веб-разработчики ругали его хозяев - EllisLab Inc. - за неповоротливость и медленное развитие этого фреймверка. Версия 2.0 не принесла ничего сверхнового в CodeIgniter, революционного скачка в развитии не произошло. Компания EllisLab Inc. неторопливо и методично патчила баги, и доводила до ума уже существующие подсистемы, писала документацию на изменения.

В то же время появилась и стала активно развиваться новая OpenSource ветка игнайтера - Kohana. Она быстро получила развёрнутую ООП структуру, была доработана концепция каскадной файловой системы, был создан центральный конфиг bootstrap, сделаны методы контроллера before и after, сделаны объект маршрутизации Route и объект ответа Request... Много чего было сделано. Кроме того, в Kohana был быстро реализован механизм HMVC.

Ничем этим CodeIgniter похвастаться не мог. Казалось бы, выбор очевиден: нужно внедрять Kohana во все поля. Но не всё так просто. На практике оказалось, что стремительное развитие Kohana сильно влияет на разработку сайтов. Например, если баг исправлялся в новой версии, то исправление заодно сопровождалось и другими изменениями, которые нарушали совместимость с предыдущей версией. На стабильное API разработчикам Kohana плевать - им нужен идеал системы, и они выпускают новые версии, совершенно не заморачиваясь с тем, что уже существующий код под ней либо не будет работать, либо потребует значительной переработки. То что вчера было обычным классом, сегодня становится синглтоном. То что вчера надо было создавать через оператор new, сегодня надо создавать через фабрику объектов. То что вчера было свойством класса, сегодня становится методом доступа. Лёгким движением руки разработчиков устоявшийся функционал класса разделяют на два других класса. И конца и края этому невидно.

Дело дошло до того, что с официального сайта Kohana была удалена официальная документация - она просто не успевала за изменениями. Новая официальная документация стала генерироваться на основе кода, и теперь не содержит таких важных разделов как User Guide по основным подсистемам. Точнее, разделы есть, но они пустые. С другой стороны, в интернете есть много информации по Kohana, даже на русском языке. Проблема в том, что она очень разрозненна и в большинстве своём устаревшая.

В общем, потратив пару месяцев на изучение фреймверка Kohana, и написав рабочий прототип проекта, я понял, что каши с Kohana не сваришь. Пользуясь им, нельзя полагаться на документацию и статьи в интернете - надо постоянно расковыривать код чтобы во-первых до конца понять концепцию одного или другого модуля, а во-вторых чтобы учесть особенности реализации. А это очень тормозит разработку.

Поэтому, когда я узнал, что в CodeIgniter с некоторых пор есть поддержка HMVC, я очень обрадовался. Впринципе, только его и не хватало в CodeIgniter, чтобы сделать разработку более простой и качественной. Оказалось, что хотя расширение HMVC не входит в стандартную поставку CodeIgniter, его очень легко установить, и многие им пользуются.

Особенности HMVC в CodeIgniter

Рсширение HMVC в CodeIgniter добавляет следующий функционал.

1. Появляется возможность работать с модулями, у которых модели, виды и контроллеры хранятся в одной поддиректории. Дерево каталогов модулей выглядит так:

modules

module1

models

views

controllers

module2

models

views

controllers

...

2. Появляется возможность вызова одного контроллера из другого посредством URI. В принципе, это и есть главное назначение HMVC в PHP-фреймверках.

Установка расширения HMVC

1. Установите CodeIgniter 2.0.x;

2. Проверьте корректность значения $config[‘base_url’];

3. Откройте URL /index.php/welcome, и удостоверьтесь, что браузер отображает страницу приветствия CodeIgniter;

4. Скачайте архив HMVC Modular Extention с официального сайта (https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/downloads, ветка default). Содержимое каталога third_party из архива поместите в каталог APPLICATION/third_party фреймверка CodeIgniter.

5. Содержимое каталога core из архива поместите в каталог APPLICATION/core.

6. Откройте URL /index.php/welcome, и удостоверьтесь, что браузер может по-прежнему отображать страницу приветствия CodeIgniter;

7. Создайте директорию APPLICATION/modules/welcome/controllers;

8. Перенесите файл APPLICATION/controllers/welcome.php в директорию APPLICATION/modules/welcome/controllers;

9. Откройте URL /index.php/welcome, и удостоверьтесь, что после переноса контроллера в модуль, браузер по-прежнему отображает страницу приветствия CodeIgniter;

10. Создайте директорию APPLICATION/modules/welcome/views;

11. Перенесите файл APPLICATION/views/welcome_message.php в директорию APPLICATION/modules/welcome/views;

12. Откройте URL /index.php/welcome, и удостоверьтесь, что после переноса файла вида в модуль, браузер по-прежнему отображает страницу приветствия CodeIgniter;

Эти действия я сделал на уже рабочем CodeIgniter-е. Ничего не поломалось, CodeIgniter продолжил работать как прежде.

После установки дополнения HMVC

Заранее следует знать, что после установки дополнения HMVC обычная схема вызова контроллера через URL продолжает по-прежнему работать. Это значит, что можно продолжать размещать контроллеры в каталоге APPLICATION/controllers и в его подкаталогах, и они будут правильно вызываться. Например, при запросе

http://mysite.ru/controller1/method2/value3

в контроллере APPLICATION/controllers/controller1.php будет вызван метод method2 с параметром value3. То есть, всё остается так же как и было в "обычном" CodeIgniter. Но дополнительно появляется возможность вызывать контроллеры модулей.

Вызов контроллеров в модулях через URL

После установки расширения HMVC, как было показано ранее, в системе появляется каталог APPLICATION/modules. В нём можно создавать подкаталоги с именами модулей, а внутри - подкаталоги controllers, views, models.

Предположим, что нам нужно сделать модуль news, который должен генерировать HTML-код новостей. В каталоге APPLICATION/modules создаем подкаталог news, а в нём создаем подкаталоги controllers, views, models.

В каталоге APPLICATION/modules/news/controllers создаём файл news.php. В нем пишем код контроллера, унаследовавшись от MX_Controller (а не от CI_Controller, это важно).

Далее, чтобы обратиться к какому-нибудь методу такого контроллера, можно воспользоваться URL следующего вида:

http://mysite.ru/<имя_модуля>/<имя_контроллера>/<имя_метода>/<переменные>

То есть, мы можем вызвать метод draw(10) контроллера news.php модуля news следующим образом:

http://mysite.ru/news/news/draw/10

Так же доступна сокращенная запись, если имя модуля и имя контроллера этого модуля совпадают:

http://mysite.ru/news/draw/10

Кстати, если будет существовать два контроллера с одинаковым именем, сделанные в "стандартном" стиле, и в HMVC-стиле, то приоритет при вызове через URL будет у HMVC контроллера.

Вызов контроллера через HMVC

Вызов одного контроллера из другого контроллера через механизм HMVC происходит с помощью статического метода modules::run(<URI>). Данный метод возвращает результат работы вызванного контроллера в виде строки.

Параметр <URI> задаётся по тем же правилам, что и URL. Например, код:

$text=Modules::run('news/news/draw');

echo $text;

вызовет в модуле news в контроллере news.php метод draw().

В HMVC-вызове есть одно ограничение: нельзя передавать параметры в строке URI. Другими словами, вызов:

$text=Modules::run('news/news/draw/10');

не сработает. Параметры следует передавать далее после строки с URI.

Вот несколько примеров написания URI:

// Имя модуля и имя контроллера разные, плюс указывается имя метода

modules::run('module/controller/method', $params, $...);

// Имя модуля и имя контроллера совпадают, плюс указывается имя метода

modules::run('module/method', $params, $...);

// Имя модуля и имя контроллера совпадают, метод index

modules::run('module', $params, $...);

Есть важное ограничение, о котором обязательно нужно знать. Невозможно вызвать через HMVC контроллер из "обычного" контроллера. Другими словами, невоможно вызвать контроллер, унаследованный от MX_Controller, из контроллера, унаследованного от CI_Controller. Если так сделать, будет выдана ошибка:

Fatal error: Cannot redeclare class CI

Но тут есть хорошее решение. Контроллеры, оформляемые в виде "обычных" контроллеров - то есть те, которые классически размещаются в каталоге APPLICATION/controllers, надо наследовать от MX_Controller (а не от CI_Controller), и тогда HMVC-вызовы будут работать везде.