Сегодня заведём разговор на такую, казалось бы простую, тему, как конфигурация сайта. То есть поговорим о таких вещах, как параметры подключения к БД, различные настройки, как всё это хранить и как со всем этим работать.
 
1: Введение
2.1: Совместная разработка (платформы)
2.2: Совместная разработка (наследование)
 
Конфигурация сервера

пля, тебе нужно идти преподавать! :) Ты так аухенно пишешь )

1. Нет никакой "конфигурации сайта", есть конфигурации инстансов объектов. Соответственно поля конфига группируем по инстансам:

2. соответственно когда создаём инстанс объекта загружаем в него ветку из конфига из файла:
 

3. В самом инстансе доступ к свойствам конфига получаем так:
 


4. Используем ArrayAccess потому что это просто удобнее.
 
5. Можем поиметь при необходимости весь конфиг

но как правило такое не нужно, т.к. удобнее работать с изолированными ветками
 
6. Для наложения индивидуальных настроек на общие удобно использовать array_replace_recursive (к сожалению только в 5.3, в 5.2 приходится её переписывать вручную).

master

Нет никакой "конфигурации сайта", есть конфигурации инстансов объектов.

Если имеется отличное мнение, не следует начинать его изложение с "нет никакой"... Я считаю что есть, даже если в системе нет вообще никаких объектов. Что есть инстанс объекта? Объект сам инстанс.
 

master

соответственно когда создаём инстанс объекта загружаем в него ветку из конфига из файла:

Объекты должны знать что-то о конфиге?

vasa_c

Что есть инстанс объекта? Объект сам инстанс.

ага
 

vasa_c

Объекты должны знать что-то о конфиге?

только о своей маленькой ветке и её структуре. для объекта бд конфиг выглядит как
array('host' => ..., 'user' => ... )

у меня все на ini-файлах бодяжится, но принцип работы слегка похож на предложенный vasa_c.

7. практика показывает что вот эти ситуации
 
$dir_root   = '/www/site.ru/htdocs';
$dir_image  = $dir_root.'/image';
$dir_thumbs = $dir_image.'/thumbs';
$dir_css    = $dir_root.'/css';
 
лучше разруливать всё же прямым указанием значений
 
$dir_root   = '/www/site.ru/htdocs';
$dir_image  = '/www/site.ru/htdocs/image';
$dir_thumbs = '/www/site.ru/htdocs/image/thumbs';
$dir_css    = '/www/site.ru/htdocs/css';
 
т.к. отдельная сложность конфигов - решить какие параметры объявить первичными, а какие вторичными на основе первичных.
 
либо
 
8. отдельно объявляем константы, а на основе констант уже формируем значения конфига
 
constants.php
define('DIR_ROOT', '/www/site.ru/htdocs');
 
config.php
return array(
'dir_image'  => DIR_ROOT.'/image',
'dir_thumbs' => DIR_ROOT.'/image/thumbs',
'dir_css' => DIR_ROOT.'/css',
)

По первой части:
 
Мне хватает глобального маccива $CONF. Т.е. использую способ, который в статье называется "Массивчик".  С ретурном из инклюда способ порадовал, я честно говоря не то чтобы не знал, но как-то не думал что можно найти практическое применение возвращаемого значения из инклюда. А вот все навороты с классами, ИМХО - навороты ради наворотов, не вижу существенных приемуществ.
 
По второй части:
 
У меня всегда есть отдельный conf в котором храняться настройки, которые теоритически могут отличаться на девелопменте и продакшене. На самомо деле, таких настроек крайне мало и меняются они редко, коннект к базе из их числа. Этот файл один раз правится на продакшене руками и больше его никто не трогает, кроме ведущего программиста. Если кто выложит - получает пизды (или автоматом исключаем его из комитов). Неэстетично, зато дешево и практично. Остальные конфы должны синхронизироваться между разработчиками так же как и остальные части проекта.
 

AlexB

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

конфиг добавляется в игнор деплой-скрипта
либо если деплой делается через свн-ап то изменённые на сервере строки остаются изменёнными, а закоммиченные изменения мерджатся в рабочей копии на сервере

В рабочей копии тоже запрещаем.

master

7. практика показывает что вот эти ситуации
 
$dir_root   = '/www/site.ru/htdocs';
$dir_image  = $dir_root.'/image';
$dir_thumbs = $dir_image.'/thumbs';
$dir_css    = $dir_root.'/css';
 
лучше разруливать всё же прямым указанием значений
 
$dir_root   = '/www/site.ru/htdocs';
$dir_image  = '/www/site.ru/htdocs/image';
$dir_thumbs = '/www/site.ru/htdocs/image/thumbs';
$dir_css    = '/www/site.ru/htdocs/css';

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

8. отдельно объявляем константы, а на основе констант уже формируем значения конфига

На любой крупной системе желательно избавляться от всех глобальны переменных, констант и лишних высокоуровневых связей.

AlexB

Неэстетично, зато дешево и практично.

Ну, мы же здесь об эстетике говорим :)
 

vasa_c

На любой крупной системе желательно избавляться от всех глобальны переменных, констант и лишних высокоуровневых связей.

констант минимум и они используются только для задания значений конфигов

Чем конфиг отличается от других подсистем? Почему ему такая честь, иметь константы, которые другим запрещены?

Очень понравилось что написал vasa_c и как написал тоже понравилось.
Сам пришел практически к таким же схемам. Опишу то что имею сверх описанного.
 
1. Абсолютно не принципиально в каком формате конфиг лежит на диске - после подгрузки это все-равно будет ветвистый ассоциативный массив типа дерево. :) Соответственно объединение глобального и частного конфигов выполняется через array_merge_recursive() - то что надо перекроется.
 
2. Про разграничение доступа к разделам конфигурации. Есть закрытый раздел конфига (назовем его "rules"), данные из него могут попасть в компоненту только при создании - Dependency Injection. Я завёл базовый класс "компонента" с таким вот конструктором:
А в закрытом разделе конфига описывается чем инициируется компонент:
Сам класс конфигурации, очевидно, имеет доступ к своим данным. Процесс создания объекта в фабрике-конфиге: