JohnCMS 7.1.0

далее можно усложнить роутер, добавив в него поддержку правил и т.д.
Потом сделать полноценный фреймворк. Или просто использовать готовые решения.

Koenig, абсолютно ничто не мешает создать в контроллере объект модели и там выполнить часть обработки.

aNNiMON, "Пока не придумал, как это красиво сделать"
Вариантов не много, подрубай в начале скрипта бутстрап (include('../bootstrap.php')) и в нем буферизируй вывод: https://github.com/Bashka/simp ... p#L18

"В каком-то вообще без слова action"
Ага, ет мой любимый вариант )

"в контейнере расширяется и заполняется данными хэдера и футера"
А че не:

{% extends "base.html" %}

"Нет, контроллер один на главной странице модуля..."
Хз, мне кажется тут класс контроллера вообще не нужен

# Mi7teR (04.05.2017 / 12:22)
используй роутинг - в зависимости от урл вызывай нужный контроллер и метод.
К примеру урл = http://site.ru/forum/index
Роутер берет из реквеста часть "forum/index"
Потом проверяет доступен ли класс

у него нет единой точки входа чтоб роутить urlы

Mi7teR, я бы с радостью, но не хочется ломать существующее обращение к страницам. Там по-старинке forum/?act=show_topic&id=xx, хоть через реврайты и выглядит как forum/idxx.

Delphinum, в шаблоне как раз и используется наследование с {% extends "base.html" %}. Но проблема в том, что шапке тоже нужны данные (счетчики, количество входящих писем для юзера и т.д.), вот они и подтягиваются в тех методах.
Про register_shutdown_function не знал, спасибо.

P.S. Что-то обсуждение сильно разрослось, нет ли более подходящей темы для этого?

aNNiMON, холиварка пыхыпышников. Хайпанем немножечко

# aNNiMON (04.05.2017 / 11:22)
ramzes, Если переменная из шапки доступна в футере, то что это, если не глобальная переменная?

Что же плохого в перезаписывании переменных? Новых объектов не создаётся, память не расходуется. Да,

Область видимости одна и та же, так что ни чего глобального.
Их вообще можно заменить на методы, и не плодить переменные.
И вызывать по необходимости, а не бездумно "заранее"
_______________
На счет подключения,
Я сделал так:
Шаблонизатор получив адрес шаблона сообщает системе о том что будет выведена информация в браузер, система в ответ подключает необходимое для этого (ну у меня футеры и хидеры отсутствуют как таковой, но это то самое место где я бы их подключал, если надо было бы) после чего отдает команду шаблонизатору на генерацию хтмл и выводит

# AlkatraZ (04.05.2017 / 11:43)
Да вот как раз таки не очевидно.

Если так рассуждать, то вообще, все можно было бы вызвать в bootstrap.php он инклюдится везде.
Что-то подобное было в 6.х.х и раньше.

Однако по "правилам хороше

По этому всегда склоняюсь к конструкции
app::config()->getDefaultTitle();
А не к переменным

# ramzes (04.05.2017 / 13:11)
По этому всегда склоняюсь к конструкции
app::config()->getDefaultTitle();
А не к переменным

Ну для начала не забывай, что у нас DI контейнер. Ты не можешь с него дернуть отдельный метод (если конечно он не зарегистрирован как сервис).
Я могу запросить DI и получить какой-то ранее зарегистрированный сервис, что собственно и делается (запрашивается сервис и загоняется в переменную).

А с конструкцией app::config() это надо похерить DI, напихать App статикой.
В принципе, сервисов у нас не так много и такой подход тоже практикуется. но у нас другое построение: DI + фабрики + конфиги. Попытка не хардкодить ядро, а сделать его гибким.

CallSctatic
Не надо ни чего жестко вписывать. Но я понял о чем ты. Это так, отвлеченно, к сути мало отношения имеет.
Ты все таки подумай, на счет дублей этого куска кода