Пространство имен конфигурации уровня приложения TurboGears 2.x

Question

Исходя из опыта Django, я привык к инфраструктуре, предоставляющей механизм конфигурации, который подходит (и предназначен) для конфигурации уровня приложения, а не только для конфигурации инфраструктуры.

Шаблон TurboGears 2.x включает в себя модуль <app_module>.config.app_cfg, который можно переопределить с помощью ini-файлов развертывания; тем не менее, это явно задокументировано как относящееся к «специфичным для TG2» настройкам, и я не вижу никакого документированного соглашения о присвоении имен или механизма пространства имен, которое бы предотвратило столкновение записи конфигурации для моего приложения с добавлением новых настроек к другим компонентам каркаса в будущем.

Предоставляет ли TurboGears 2.x или набор принятых передовых методик для разработчиков TG2 (вставка и т. Д.), Какой-либо механизм управления конфигурацией для приложений, созданных на TG2, не относящихся непосредственно к TG2? Если повторное использование механизма конфигурации TG2 является общепринятым, есть ли общепринятая практика для управления пространством имен конфигурации?

Answer 1

config в TurboGears2 поддерживает сложные структуры, например, вы можете объявить опции для вашего приложения внутри myapp.option1 myapp.option2 и так далее.Они будут доступны внутри вашего приложения как tg.config['myapp.option1'] и tg.config.myapp.option1.

Таким образом, вы избежите столкновений.

Параметры могут быть установлены как в development.ini, так и config.app_cfg.

Например, если вы поместите внутрь вашего app_cfg

base_config['myapp.option1'] = 'FOOBAR'

, строка FOOBAR будет доступна из tg.config.myapp.option1

Обратите внимание, что base_config объектперезаписывает параметры, загруженные из файла конфигурации .ini .