AlkatraZ, если очень постараться, то можно куй в балалайку превратить, но зачем? ) Не вижу смысла насильно упрощать архитектуру ради 1-2 разработчиков, которым лень изучить основы ООП в PHP, но в остальном дело конечно твое )
Delphinum, согласен
я бы просто зачищал буфер после модуля.
нет ни чего на экране? так ты отдай данные вьюверу это не больно
шаблонизатор нативный и будет счастье
Koenig, проблема в том, что шаблонизаторов тоже есть множество, на базе чистого php, на базе smarty, на базе twig и т.д. А что если твой модуль хочет использовать smarty, а модуль, от которого зависит твой модуль хочет использовать php? Так вот и это не проблема с модульной архитектурой
# Delphinum (31.01.2017 / 21:57)
Koenig, проблема в том, что шаблонизаторов тоже есть множество, на базе чистого php, на базе smarty, на базе twig и т.д. А что если твой модуль хочет использовать smarty, а модуль, от которого зависи
Это о чём-то глобальном или об одной конкретной CMS идёт речь?
Мне кажется CMS должна задавать некие правила разработки под неё, а не городить тучу велосипедов из тучи шаблонизаторов.
Я б наверное при виде такого веломотобиля закрыл бы и отказался бы от работы
Simba, я давно не рассматриваю решения в виде монолитов. По моему они уже отжили свое. В моем решении я предлагаю использовать пустой каркас на основе middleware и модульной архитектурой, а готовые решения для пользователей будут представляться в виде дистрибутивов. Дистр это каркас + пачка модулей + какие то свистоперделки для удобства пользователя. Благодаря такому подходу, можно из одних и тех же модулей собирать как дистр блога, так и дистр лендинга, без необходимости копипасить или велосипедить.
Проще говоря, готовое решение это дистрибутив, а то что делаю я, это скелет и набор модулей, из которых можно этот дистрибутив собрать. Дистрибутивы собирать должны не пользователи, а тоже разработчики, пользователям лезть в исходники вообще не рекомендуется.