来自Django背景,我习惯于提供一种适用于(并且打算)应用层配置的配置机制的框架,而不仅仅是框架配置。
TurboGears 2.x模板包含一个<app_module>.config.app_cfg
模块,可以通过部署ini文件覆盖;但是,这明确记录为“TG2特定”设置,我没有看到任何类型的命名约定或命名空间机制,这会阻止我为我的应用程序提出的配置条目与添加的新设置冲突未来的其他框架组件。
TurboGears 2.x是否为TG2开发人员(粘贴等)提供或接受了一套公认的最佳实践,包括管理基于TG2构建的应用程序的配置的任何机制,而不是特定于TG2本身?如果重用TG2配置机制是常规的,是否有任何可接受的配置命名空间管理实践?
答案 0 :(得分:3)
TurboGears2中的config
支持复杂结构,例如,您可以在myapp.option1
myapp.option2
内为应用程序声明选项,依此类推。它们可以在您的应用程序中以tg.config['myapp.option1']
和tg.config.myapp.option1
进行访问。
这样可以避免碰撞。
可以在development.ini
和config.app_cfg
中设置选项。
例如,如果你放入app_cfg
base_config['myapp.option1'] = 'FOOBAR'
可以从tg.config.myapp.option1
注意base_config
对象会覆盖从 .ini 配置文件加载的选项。