Одним из самых больших и горячих обсуждений о будущем CodeIgniter 4, было обсуждение о поддержке и возможности использования модулей/HMVC.
Большинство было за то, чтобы в CodeIgniter по умолчанию можно было использовать два шаблона проектирования веб-приложений: MVC и HMVC. Однако совет CI пришел к мнению, что внедрение HMVC противоречит основных принципам и идеологии фреймворка в целом.
Поддержка модулей/HMVC
Как уже стало ясно, в CodeIgniter 4 не будет поддержки ни HMVC, ни модулей. Не будет официального определения структуры модуля как такового. По крайней мере, там не будет модульности в том виде, в какой ее можно представить в Yii Framework или Drupal CMS.
Нет никакой иерархической загрузки классов при помощи различных каталогов.
Если все это так, то как мы можем поддерживать любую форму модулей и строить удобные модульные веб-приложения? На это у нас имеется автозагрузка и пространства имен.
Автозагрузка и пространства имен
Теперь фреймворк поставляется с встроенным PSR-4 совместимым автозагрузчиком. Нет необходимости использовать Composer. Если все же вы желаете его использовать, то его можно встроить в качестве дополнения.
Но почему бы просто не использовать Composer в качестве основного загрузчика? Лонни Эцелл, разработчик CodeIgniter 4, который сейчас занимается построением ядра фреймворка, сторонник использования Composer в CodeIgniter. Однако, разработчики пришли к выводу что использование Composer будет не правильным решением. Например, для некоторых хостингов Composer будет проблематичным, не везде его можно применять. Еще необходимо поддерживать функционал, который задействует Composer.
Системные файлы и файлы приложения могут быть в пространстве имен. Системные файлы в пространстве имен CodeIgniter, а каталог приложений в пространстве имен App по умолчанию.
Простой пример
Представьте, что мы создаем модуль блога. Первое, что нужно сделать, это принять решение о пространстве имен, а затем решить где разместить файлы. Для примера будет использоваться каталог Standard, в котором будут все необходимые файлы модуля. Структура папок может выглядеть примерно так:
/application
/standard
/Blog
/Config
/Controllers
/Helpers
/Libraries
/Models
/Views
/system
Чтобы система знала, где найти файлы, нужно открыть файл:
/application/Config/Autoload.php
где следует указать:
$psr4 = [
'Config' => APPPATH.'Config',
APP_NAMESPACE.'\Controllers' => APPPATH.'Controllers',
APP_NAMESPACE => realpath(APPPATH),
'Standard' => APPPATH.'../standard'
];
Теперь, система может найти все что нужно и использовать в любом месте:
namespace Standard\Blog;
use Standard\Blog\Models\BlogModel;
use Standard\Blog\Libraries\BlogLibrary;
use Standard\Blog\Config\Blog as BlogConfig;
class BlogController extends \CodeIgniter\Controller
{
public function index()
{
$model = new BlogModel();
$blogLib = new BlogLibrary();
$config = new BlogConfig();
}
}
Загрузка Helpers
В нашем примере, мы могли бы иметь файл
/standard/Blog/Helpers/BlogHelper.php.
Для загрузки класса используем функцию load_helper ():
load_helper('Standard\Blog\Helpers\BlogHelper');
Функция поможет найти хелпер и загрузить его.
Загрузка View
При использовании шаблона модуля, представления могут быть загружены при помощи функции load_view ().
echo load_view('Standard\Blog\Views\index', $data);
load_helper('Standard\Blog\BlogHelper');
echo load_view('Standard\Blog\index', $data);
Хотя, это не единственный способ, которым вы можете структурировать вещи в вашем приложении.
ПРИМЕЧАНИЕ: Примеры основаны на коде предварительной версии и вся специфика может быть изменена на любую другую.
Ссылки по теме
Источник: Modules in CodeIgniter 4
CodeIgniter Wikipedia: ru.wikipedia.org/wiki/CodeIgniter
Официальный сайт CodeIgniter: www.codeigniter.com
Официальный форум CodeIgniter: forum.codeigniter.com
CodeIgniter 4: https://habrahabr.ru/post/275657/
CI Community Apps: https://habrahabr.ru/post/276375/
Requests и Responses в CodeIgniter 4: https://habrahabr.ru/post/278489/
Внедрение зависимостей в CodeIgniter 4: https://habrahabr.ru/post/278641/
Маршрутизация в CodeIgniter 4: https://habrahabr.ru/post/278873/
AlexLeonov
Коллеги, вы можете ставить мне сколько угодно минусов, но всё-таки разработчики этого фреймворка упоротые. Ну явно они что-то употребляют.
Чем же вдруг общепринятая практика противоречит принципам фреймворка? Может нафиг такие принципы?
Может быть это проблема некоторых хостингов? Очнитесь, на дворе 2016 год!
Это не PSR-4. Вообще.
ЭТО НЕ PSR-4!!!
facepalm.jpg
Уважаемый коллега condor-bird, спасибо за ваш труд, но вы бы хоть теги ставили правильные. Например "Юмор" или "Как не надо делать"...
condor-bird
В принципе соглашусь с вами. На данное время имеются непонятные моменты, говорится одно, пишется другое. Но, думаю, что они еще не раз будут переделывать и улучшать, так как это не окончательная версия. Мне тоже не понравились некоторые функции. Надеюсь, что переделают и все будет правильно.
Что касается политики фреймворка, которая наблюдается уже давно и продолжается до сих пор, то да, она в какой-то степени неадекватная или скорей всего сильно жесткая. Сложилось впечатление, что они не всегда готовы прислушиваться к мнению большинства участников сообщества. Видят везде заговоры и т.п. Да, явно они что-то употребляют :)
Лонни по видимому неравнодушен к Lavarel, о чем сам неоднократно упоминал, поэтому, возможно, какие-то фишки будут схожи по возможностям или напоминать возможности компонентов Laravel. Но в целом, это уже давно ясно, они не желают идти по стопам уже имеющихся и внедрять в себя кучу всего, например, как это сделано в Yii, где целый набор всего (в хозяйстве все пригодится). Это же дело коснулось и модульности, которую посчитали совершенно лишней. Поэтому отделались автозагрузкой и пространством имен.
В скелете оставят лишь самое необходимое. Пару компонентов версии 3x (вроде корзины, javascript, trackback) удалят. Не будет также возможности использования файлов с приставкой MY_. Пакетов тоже не будет. Пару классов вынесут в отдельно подключаемые дополнения: класс для работы с ftp, XML-RPC, zip, класс оформления Typography, класс парсинга шаблонов для вставки всевдо-переменных в view.
Auth и users библиотеки нужно будет пилить самим, если конечно же, не будет сформировано CI Community Apps. Но про него они пока молчат. Думаю, что это дело разработчикам по боку. Возможно в сообществе найдутся пользователи, которые пожелают заняться дополнениями.
Причин для смеха над кодом здесь есть и будет еще больше, не сомневайтесь :) Наверное, напишу еще пару интересных или не очень интересных статей/заметок про фреймворк до релиза четвертой версии.