Comments 15
ммм одна неприятная особенность — нужно было разширять класс так чтобы он наследовал Zend_Config_Ini а не был дополнительным инструментом.
Я специально не наследовал Ini или Xml, чтобы подстановку можно было выполнять в любом типе конфигов.
При чем тут Zend_Config_Ini?
Ведь в данном случае нет зависимости от формата конфига. Можно юзать хоть ini, хоть xml, хоть array.
2 автор: до кучи можно сделать парсинг плейсхолдеров по запросу секций, а не при инициализации конфига. Мелочь, а приятно.
Ведь в данном случае нет зависимости от формата конфига. Можно юзать хоть ini, хоть xml, хоть array.
2 автор: до кучи можно сделать парсинг плейсхолдеров по запросу секций, а не при инициализации конфига. Мелочь, а приятно.
С одной стороны — можно, а с другой — пока нагрузки низкие, погоды это не сделает, а когда нагрузки возрастут, то преобразованный конфиг просто целиком кладется в кэш.
В данном случае я стараюсь придерживаться принципа KISS.
В данном случае я стараюсь придерживаться принципа KISS.
Ну я вообще имел ввиду избавление от этих 2 строк:
// присваиваем путь к корню проекта переменной конфига
$configRaw->path->root = $rootPath;
// выполняем подстановку значений, превращая «сырой» конфиг в «обработанный»
$config = Inf_Config_Placeholder($configRaw);
они избыточны. Можно наследовать от фабрики zend_config и прямо там выполнять подстановку.
// присваиваем путь к корню проекта переменной конфига
$configRaw->path->root = $rootPath;
// выполняем подстановку значений, превращая «сырой» конфиг в «обработанный»
$config = Inf_Config_Placeholder($configRaw);
они избыточны. Можно наследовать от фабрики zend_config и прямо там выполнять подстановку.
У Zend_Config нет фабрики.
И я не ставил перед собой цель её написать :)
Так что получилось то, что получилось.
И я не ставил перед собой цель её написать :)
Так что получилось то, что получилось.
Ну эти две строки в данном случае ни сколько не избыточны. Ведь «путь к корню проекта» как-то должен попасть в конфиг, для подстановки в плейсхолдеры. И тут выбран самый простой вариант: взять конфиг; добавить необходимые свойства; обгадить конфиг. KISS.
Другое дело, можно $rootPath сохранить в реестре(это значение много где может пригодится), и научить конфиг «общаться» с этим реестром. Но в вышеописанном варианте конфиг по сути сам будет является реестром(его частью? :)), который один раз инициализировался в бутстрапе и потом юзается.
Другое дело, можно $rootPath сохранить в реестре(это значение много где может пригодится), и научить конфиг «общаться» с этим реестром. Но в вышеописанном варианте конфиг по сути сам будет является реестром(его частью? :)), который один раз инициализировался в бутстрапе и потом юзается.
Другое дело, можно $rootPath сохранить в реестре(это значение много где может пригодится), и научить конфиг «общаться» с этим реестром. Но в вышеописанном варианте конфиг по сути сам будет является реестром(его частью? :)), который один раз инициализировался в бутстрапе и потом юзается.
Ой-ой-ой, какие ужасные вещи вы говорите.
ИМХО, реестр — это антипаттерн, который компенсирует недостатки архитектуры проекта и поощряет добавление неявных связей между компонентами.
Если $rootPath понадобится каким-то другим компонентам системы, то пускай они и берут его из конфига :)
Ну, на самом деле, не напрямую из конфига, а экшн контроллер (например) будет конфигурировать эти «другие компоненты», получая конфиг из бутстрапа, который он, в свою очередь, получает через $this->getInvokeArg('bootstrap').
Как-то так.
хм. а мне больше по душе xml, но это уже впрочем не по теме…
>>> выполнение бесконечной рекурсии занимает 7 секунд даже на самых современных серверах
бесконечная рекурсия за 7 секунд возможна???
бесконечная рекурсия за 7 секунд возможна???
Sign up to leave a comment.
Подстановка значений в Zend_Config