Наследование конфигов в Zend_Config

[drJonnie]

Соглашусь, самый правильный вариант. Также хочу добавить, что в питоне (django) подобное делаем с помощью строки в конце конфигурационного файла:

try:
    from local_settings import *
except ImportError:
    pass

Понятно, что local_settings централизовано добавлен в игнор и репозитории его нет.

[darkstyler]

Хорошая идея. Сейчас учту это в своем проекте.

[san]

Хорошая статья, спасибо.

[zerkms]

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

a.b.c.d.ini -> b.c.d.ini -> c.d.ini -> d.ini

м?

[LaggyLuke]

Можно и так, просто меня полностью устроила эта реализация.
Мне тяжело представить себе ситуацию, когда каскадное наследование будет полезно — скорее, оно будет стимулировать разработчиков к тому, чтобы… эмм… использовать его :), что может привести к появлению многоуровневой иерархии конфигов в проекте — имхо, перебор.

Кроме того, как сказал какой-то умный человек: самый лучший код — это тот код, которого нет. Он не содержит ошибок, его не надо тестировать, отлаживать, поддерживать и т.д. :)
Так что как только я понял, что для получения необходимой мне функциональности стандартную реализацию Zend_Config наследовать не обязательно, я был только рад.

[zerkms]

>> «Мне тяжело представить себе ситуацию, когда каскадное наследование будет полезно»
а о чём ты написал топик тогда? :-) выроди мой пример до 2х уровней и будет абсолютно твой пример :-)

ps: можно и не наследовать, кстати. ещё лучше реализовать некое подобие the builder pattern, класса, который будет собирать нужный тебе конфиг :-)

[LaggyLuke]

а о чём ты написал топик тогда? :-)

А это топик-сюрприз: название говорит «наследование», а на самом деле речь идёт о том, как два конфига слить в один :)

На самом деле, я хотел сделать акцент на идеологию, а не на реализацию.
Плюс руководствовался принципом KISS.

[zerkms]

как мне кажется, идея именно с наследованием весьма клёвая :-) особенно в контексте «своего» и «продакшн» конфигов.

ps: перефразирую вас
«а на самом деле речь идёт о том, как два конфига слить в один»
— >>
«о, а в конфигах зенда есть merge()!»
;-)

[LaggyLuke]

На самом деле, когда я перечитывал топик перед опубликованием и осознал, насколько он раздутый получился, именно такая мысль у меня и возникла: удалить всё нафиг, написать в теме «У Zend_Config есть метод merge()!» и в контенте — «subj» :)

[Kirpichtion]

Короче, Склифасовский :) Имхо, примера с кодом было бы достаточно.

[LaggyLuke]

Уж простите, люблю всё «разжёвывать», чтобы даже у человека «не в теме» вопросов не оставалось.
А первые пару строчек ведь не зря написал :)

[stfalcon]

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

ЗЫ. Только локальный конфиг я бы назвал типа «config.local.ini», а основной оставил бы так как есть «config.ini». Так привычнее.

[mstarrr]

Нда, наследование конфигов — интересная идея.

У меня вот другой подход к данной проблеме: для констант юзаем фукнцию

GetConstant($sKey,$sDafultValue) — и в конфиге только настройки базы. Все остальное правится любо заказчиком в модуле админки Константы, либо програмерами в том же модуле.

[mstarrr]

Код на пхп:
//-----------------------------------------------------------------------------------------------
/**
* Updates or creates constants used all over the project
*/
function UpdateConstant($sKey, $sValue) {
Base::$db->Execute(«insert into constant(key_,value) values ('».$sKey."','".mysql_real_escape_string($sValue)."')
on duplicate key update value='".mysql_real_escape_string($sValue)."'");
}
//-----------------------------------------------------------------------------------------------
function GetConstant($sKey,$sDefaultValue='') {
if (!isset(Base::$aConstant[$sKey]['value'])) {
Base::$db->Execute(«insert into constant(key_,value) values ('$sKey','$sDefaultValue')»);
Base::$aConstant[$sKey]['value']=$sDefaultValue;
return $sDefaultValue;
}
return Base::$aConstant[$sKey]['value'];
}
//-----------------------------------------------------------------------------------------------

[mstarrr]

таблица:
CREATE TABLE IF NOT EXISTS `constant` (
`id` int(11) NOT NULL auto_increment,
`key_` varchar(255) NOT NULL,
`value` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `key_` (`key_`)
)

[mstarrr]

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

[mecommayou]

Прикольна идея мерджить конфиги, оссобенно учитывая зенд_аппликейшин и описание ресурсов в конфиге… там дефолтный конфиг получается на 1к строк…

[stfalcon]

опять наткнулся на эту тему. оказалось, что с выходом ZF 1.8.2 все можно делать намного проще. просто в конфиге написать что-то типа:
config = APPLICATION_PATH "/config/conf.local.ini"

вот эта тема zendframework.ru/forum/index.php?topic=1302.0
веллкам на форум зендфреймоврк.ру ;)

[LaggyLuke]

Хм, интересно.
Совсем недавно изучал код Zend_Application, но видать эту пару строчек пропустил.
Хотя тут возникают сложности, например локальный конфиг обязательно должен присутствовать — использовать только общий конфиг уже не получится.

Тем не менее, спасибо за наводку, сейчас обновлю статью.

[Makor]

А в Zend 1.11.2 я столкнулся с багом, при котором локальные конфиги не работают… А в 1.10dev все было ок :)

В результате оказалось что в 11 версии они почему то поменяли порядок массивов при merge, в результате локальные настройки затирались…