JohnCMS 7.1.0

Mi7teR, изначально когда готовили семёрку, переменные нужные модули сами определяли, ядро минимум их содержало

# ramzes (03.05.2017 / 17:56)
не, ни че) уточнил просто, серьезно ли это)

Ну у нас же модули не ООП, а процедурный код.
Потому приходится каждый раз дергать из ядра нужные объекты.

# AlkatraZ (03.05.2017 / 19:23)
Ну у нас же модули не ООП, а процедурный код.
Потому приходится каждый раз дергать из ядра нужные объекты.

зачем одно и то же в футе, хедере, и видимо в самом скрипте?
они у тебя в раздельных областях видимости что ли?
их достаточно в хедере вызвать же, и дальше эти переменные будут доступны.
или у тебя там есть какое то разделение областей и переменные из шапки не доступны в ногах?

it is stable version for use ? Admin

ramzes, глобальные переменные - зло. Решишь потом переписать head.php или ещё что-то, и у тебя переменные не будут доступны в остальных скриптах. Да и, открывая end.php, сразу видно, какие переменные как используются, не нужно догадываться и смотреть, что там где определено.
В общем, это не то, на чём следует экономить.

# aNNiMON (04.05.2017 / 10:16)
ramzes, глобальные переменные - зло. Решишь потом переписать head.php или ещё что-то, и у тебя переменные не будут доступны в остальных скриптах. Да и, открывая end.php, сразу видно, какие переменные

Это не глобальные переменные, это раз.
Это бессмысленное перезаписывание переменных, это два.
Это непродуманность архитектуры, это три.
Ни какая экономия тут не при чем

ramzes, Если переменная из шапки доступна в футере, то что это, если не глобальная переменная?

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

И о какой архитектуре речь, если на момент создания движка таких слов никто не знал? Переписать всё на контроллеры с одной точкой входа можно, но вот так сразу это не выйдет, такова уж цена процедурного подхода.

Можно просто обернуть выхлоп скриптов в layout и будет вам счастье

# ramzes (03.05.2017 / 22:53)
зачем одно и то же в футе, хедере, и видимо в самом скрипте?
они у тебя в раздельных областях видимости что ли?
их достаточно в хедере вызвать же, и дальше эти переменные будут доступны.
или у тебя

Да вот как раз таки не очевидно.

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

Однако по "правилам хорошего тона", да и для удобства в IDE, надо четко знать, откуда берется твоя переменная, или объект? Залез ты к примеру в какой-нибудь include файл форума, или профиля. Смотришь, там переменная $config откуда она берется неизвестно, в текущий файл то ничего не инклюдится. А куда инклюдится сам файл, ни IDE ни кодер с первого взгляда не знают.
Потому IDE и подсвечивают подобное как "потенциально не инициализированная переменная".

Ну и второй аргумент, который вытекает из первого и который для меня намного важнее - это рефакторинг и отслеживание (в IDE разумеется) использования переменных и объектов. Если переменные не будут четко инициализированы, такая связь теряется.

# AlkatraZ (04.05.2017 / 11:43)
А куда инклюдится сам файл, ни IDE ни кодер с первого взгляда не знают.
Потому IDE и подсвечивают подобное как "потенциально не инициализированная переменная".

/* @var $config \some\namespace\Config */

https://ru.wikipedia.org/wiki/PHPDoc