1

来自 Django 背景，我习惯于框架提供一种配置机制，该机制适用于（并且适用于）应用层配置，而不仅仅是框架配置。

TurboGears 2.x 模板包含一个<app_module>.config.app_cfg模块，可以通过部署 ini 文件覆盖该模块；但是，这被明确记录为“特定于 TG2”的设置，并且我没有看到任何类型的命名约定或命名空间机制记录在案，这会阻止我为我的应用程序提出的配置条目与添加的新设置发生冲突到未来的其他框架组件。

TurboGears 2.x 是否提供，或者为 TG2 开发人员（粘贴等）提供的一组公认的最佳实践是否包括任何机制来管理基于 TG2 构建的应用程序的配置，而不是特定于 TG2 本身？如果重用 TG2 配置机制是常规的，那么配置命名空间管理是否有任何公认的做法？

4

1 回答 1

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'

FOOBAR 字符串可以从tg.config.myapp.option1

请注意，base_config对象会覆盖从.ini配置文件加载的选项。

于 2012-03-14T21:45:45.137 回答