История изменений

А, вообще, использование глобальных конфигов оказалсь порочной практикой, так что я их использование понемногу сворачиваю. Только чисто хостовые настройки, типа доступа к БД, корневых доменов и т.п.

А то в свете Web-фреймворки: где есть и как реализована (и как называется) «мультипроектность»? стали при смешении проектов конфликты вылезать.

Скажем, задан корень сайта как config_set('main_site_url', 'http://my-site.tld'). И используется в классах url, генерируемые от этого параметра. Потом, бац, подключаем к работе второй проект, с таким же именем переменной. И иди потом разруливай внешние ссылки на объекты :)

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

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

Тем более, что есть гибкие классы-конфигураторы, так что часто в классе проекта достаточно указать только класс его конфигуратора. Так часто он из двух строчек на yaml и состоит:

extends: bors_page
config_class: aviaport_admin_config

А уже оно скомпилится в кеш в виде:

<?php

class aviaport_admin_meta_page extends bors_page
{

    function config_class() { return 'aviaport_admin_config'; }

    function class_file() { return ec('/var/www/admin.aviaport.ru/bors-site/classes/aviaport/admin/meta/page.yaml'); }
}

А, вообще, использование глобальных конфигов оказалсь порочной практикой, так что я их использование понемногу сворачиваю. Только чисто хостовые настройки, типа доступа к БД, корневых доменов и т.п.

А то в свете Web-фреймворки: где есть и как реализована (и как называется) «мультипроектность»? стали при смешении проектов конфликты вылезать.

Скажем, задан корень сайта как config_set('main_site_url', 'http://my-site.tld'). И используется в классах url, генерируемые от этого параметра. Потом, бац, подключаем к работе второй проект, с таким же именем переменной. И иди потом разруливай внешние ссылки на объекты :)

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

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

Тем более, что есть гибкие классы-конфигураторы, так что часто в классе проекта достаточно указать только класс его конфигуратора. Так часто он из двух строчек на yaml и состоит:

extends: bors_page
config_class: aviaport_admin_config

А, вообще, использование глобальных конфигов оказалсь порочной практикой, так что я их использование понемногу сворачиваю. Только чисто хостовые настройки, типа доступа к БД, корневых доменов и т.п.

А то в свете Web-фреймворки: где есть и как реализована (и как называется) «мультипроектность»? стали при смешении проектов конфликты вылезать.

Скажем, задан корень сайта как config_set('main_site_url', 'http://my-site.tld'). И используется в классах url, генерируемые от этого параметра. Потом, бац, подключаем к работе второй проект, с таким же именем переменной. И иди потом разруливай внешние ссылки на объекты :)

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

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

Тем более, что есть гибкие классы-конфигураторы, так что часто в классе проекта достаточно указать только класс его конфигуратора. Так часто он из двух строчек на yaml и идут:

extends: bors_page
config_class: aviaport_admin_config