Комментарии 21
Соглашусь, самый правильный вариант. Также хочу добавить, что в питоне (django) подобное делаем с помощью строки в конце конфигурационного файла:
Понятно, что local_settings централизовано добавлен в игнор и репозитории его нет.
try:
from local_settings import *
except ImportError:
pass
Понятно, что local_settings централизовано добавлен в игнор и репозитории его нет.
Хорошая идея. Сейчас учту это в своем проекте.
Хорошая статья, спасибо.
почему бы тогда не переписать конструктор так, чтобы он сам загружал рекурсивно конфиги и сливал данные?
a.b.c.d.ini -> b.c.d.ini -> c.d.ini -> d.ini
м?
a.b.c.d.ini -> b.c.d.ini -> c.d.ini -> d.ini
м?
Можно и так, просто меня полностью устроила эта реализация.
Мне тяжело представить себе ситуацию, когда каскадное наследование будет полезно — скорее, оно будет стимулировать разработчиков к тому, чтобы… эмм… использовать его :), что может привести к появлению многоуровневой иерархии конфигов в проекте — имхо, перебор.
Кроме того, как сказал какой-то умный человек: самый лучший код — это тот код, которого нет. Он не содержит ошибок, его не надо тестировать, отлаживать, поддерживать и т.д. :)
Так что как только я понял, что для получения необходимой мне функциональности стандартную реализацию Zend_Config наследовать не обязательно, я был только рад.
Мне тяжело представить себе ситуацию, когда каскадное наследование будет полезно — скорее, оно будет стимулировать разработчиков к тому, чтобы… эмм… использовать его :), что может привести к появлению многоуровневой иерархии конфигов в проекте — имхо, перебор.
Кроме того, как сказал какой-то умный человек: самый лучший код — это тот код, которого нет. Он не содержит ошибок, его не надо тестировать, отлаживать, поддерживать и т.д. :)
Так что как только я понял, что для получения необходимой мне функциональности стандартную реализацию Zend_Config наследовать не обязательно, я был только рад.
>> «Мне тяжело представить себе ситуацию, когда каскадное наследование будет полезно»
а о чём ты написал топик тогда? :-) выроди мой пример до 2х уровней и будет абсолютно твой пример :-)
ps: можно и не наследовать, кстати. ещё лучше реализовать некое подобие the builder pattern, класса, который будет собирать нужный тебе конфиг :-)
а о чём ты написал топик тогда? :-) выроди мой пример до 2х уровней и будет абсолютно твой пример :-)
ps: можно и не наследовать, кстати. ещё лучше реализовать некое подобие the builder pattern, класса, который будет собирать нужный тебе конфиг :-)
а о чём ты написал топик тогда? :-)А это топик-сюрприз: название говорит «наследование», а на самом деле речь идёт о том, как два конфига слить в один :)
На самом деле, я хотел сделать акцент на идеологию, а не на реализацию.
Плюс руководствовался принципом KISS.
Короче, Склифасовский :) Имхо, примера с кодом было бы достаточно.
Красивое решение! Тоже задумывался о решении такой проблемы. Хоть она для меня пока не актуальна, но все равно спасибо, думаю пригодится.
ЗЫ. Только локальный конфиг я бы назвал типа «config.local.ini», а основной оставил бы так как есть «config.ini». Так привычнее.
ЗЫ. Только локальный конфиг я бы назвал типа «config.local.ini», а основной оставил бы так как есть «config.ini». Так привычнее.
Нда, наследование конфигов — интересная идея.
У меня вот другой подход к данной проблеме: для констант юзаем фукнцию
GetConstant($sKey,$sDafultValue) — и в конфиге только настройки базы. Все остальное правится любо заказчиком в модуле админки Константы, либо програмерами в том же модуле.
У меня вот другой подход к данной проблеме: для констант юзаем фукнцию
GetConstant($sKey,$sDafultValue) — и в конфиге только настройки базы. Все остальное правится любо заказчиком в модуле админки Константы, либо програмерами в том же модуле.
Код на пхп:
//-----------------------------------------------------------------------------------------------
/**
* 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'];
}
//-----------------------------------------------------------------------------------------------
//-----------------------------------------------------------------------------------------------
/**
* 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'];
}
//-----------------------------------------------------------------------------------------------
Забыл самое главное сказать — каждый, кто вводит константу — добавляет дефолтное значение, чтобы у других не поламался код.
НЛО прилетело и опубликовало эту надпись здесь
Прикольна идея мерджить конфиги, оссобенно учитывая зенд_аппликейшин и описание ресурсов в конфиге… там дефолтный конфиг получается на 1к строк…
опять наткнулся на эту тему. оказалось, что с выходом ZF 1.8.2 все можно делать намного проще. просто в конфиге написать что-то типа:
config = APPLICATION_PATH "/config/conf.local.ini"
вот эта тема zendframework.ru/forum/index.php?topic=1302.0
веллкам на форум зендфреймоврк.ру ;)
config = APPLICATION_PATH "/config/conf.local.ini"
вот эта тема zendframework.ru/forum/index.php?topic=1302.0
веллкам на форум зендфреймоврк.ру ;)
Хм, интересно.
Совсем недавно изучал код Zend_Application, но видать эту пару строчек пропустил.
Хотя тут возникают сложности, например локальный конфиг обязательно должен присутствовать — использовать только общий конфиг уже не получится.
Тем не менее, спасибо за наводку, сейчас обновлю статью.
Совсем недавно изучал код Zend_Application, но видать эту пару строчек пропустил.
Хотя тут возникают сложности, например локальный конфиг обязательно должен присутствовать — использовать только общий конфиг уже не получится.
Тем не менее, спасибо за наводку, сейчас обновлю статью.
А в Zend 1.11.2 я столкнулся с багом, при котором локальные конфиги не работают… А в 1.10dev все было ок :)
В результате оказалось что в 11 версии они почему то поменяли порядок массивов при merge, в результате локальные настройки затирались…
В результате оказалось что в 11 версии они почему то поменяли порядок массивов при merge, в результате локальные настройки затирались…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наследование конфигов в Zend_Config