LaggyLuke2 июл 2009 в 22:14

Подстановка значений в Zend_Config

2 мин

758

Комментарии 15

Silverstorm 2 июл 2009 в 23:31

ммм одна неприятная особенность — нужно было разширять класс так чтобы он наследовал Zend_Config_Ini а не был дополнительным инструментом.

LaggyLuke 3 июл 2009 в 05:56

Я специально не наследовал Ini или Xml, чтобы подстановку можно было выполнять в любом типе конфигов.

uwl 3 июл 2009 в 06:13

При чем тут Zend_Config_Ini?
Ведь в данном случае нет зависимости от формата конфига. Можно юзать хоть ini, хоть xml, хоть array.

2 автор: до кучи можно сделать парсинг плейсхолдеров по запросу секций, а не при инициализации конфига. Мелочь, а приятно.

LaggyLuke 3 июл 2009 в 06:22

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

Silverstorm 3 июл 2009 в 10:17

Ну я вообще имел ввиду избавление от этих 2 строк:

// присваиваем путь к корню проекта переменной конфига
$configRaw->path->root = $rootPath;

// выполняем подстановку значений, превращая «сырой» конфиг в «обработанный»
$config = Inf_Config_Placeholder($configRaw);

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

LaggyLuke 3 июл 2009 в 10:47

У Zend_Config нет фабрики.
И я не ставил перед собой цель её написать :)
Так что получилось то, что получилось.

uwl 3 июл 2009 в 11:34

Ну эти две строки в данном случае ни сколько не избыточны. Ведь «путь к корню проекта» как-то должен попасть в конфиг, для подстановки в плейсхолдеры. И тут выбран самый простой вариант: взять конфиг; добавить необходимые свойства; обгадить конфиг. KISS.

Другое дело, можно $rootPath сохранить в реестре(это значение много где может пригодится), и научить конфиг «общаться» с этим реестром. Но в вышеописанном варианте конфиг по сути сам будет является реестром(его частью? :)), который один раз инициализировался в бутстрапе и потом юзается.

LaggyLuke 3 июл 2009 в 11:50

Другое дело, можно $rootPath сохранить в реестре(это значение много где может пригодится), и научить конфиг «общаться» с этим реестром. Но в вышеописанном варианте конфиг по сути сам будет является реестром(его частью? :)), который один раз инициализировался в бутстрапе и потом юзается.

Ой-ой-ой, какие ужасные вещи вы говорите.
ИМХО, реестр — это антипаттерн, который компенсирует недостатки архитектуры проекта и поощряет добавление неявных связей между компонентами.

Если $rootPath понадобится каким-то другим компонентам системы, то пускай они и берут его из конфига :)
Ну, на самом деле, не напрямую из конфига, а экшн контроллер (например) будет конфигурировать эти «другие компоненты», получая конфиг из бутстрапа, который он, в свою очередь, получает через $this->getInvokeArg('bootstrap').
Как-то так.

uwl 3 июл 2009 в 12:33

На истинность никак не претендовал :)

Паттерны не панацея. Есть проекты, и есть решения… не обязательно одинаковые при этом.

з.ы. неужели Вы никогда не пользуетесь этим антипаттерном? ;)

LaggyLuke 3 июл 2009 в 13:20

Раньше пользовался.
Но даже тогда мне было стыдно и я никому не рассказывал о таких вещах :)
Сейчас позволяю себе только редкие поблажки в виде синглтонов :)