2012-03-04 21 views
1

從Django的背景來看,我習慣於提供一種適用於應用層配置而不是框架配置的配置機制。TurboGears 2.x應用程序層配置命名空間

TurboGears 2.x模板包含一個<app_module>.config.app_cfg模塊,該模塊可以通過部署ini文件進行覆蓋;然而,這明確記錄爲「特定於TG2」的設置,並且我沒有看到任何形式的命名約定或命名空間機制,它們會阻止我爲我的應用程序添加的配置條目與添加的新設置相沖突到未來的其他框架組件。

TurboGears 2.x是否提供了TG2開發人員接受的最佳實踐(粘貼等)?是否包含任何管理TG2上構建的應用程序配置的機制,而不是專門針對TG2本身?如果重複使用TG2配置機制是常規的,是否有配置名稱空間管理的公認慣例?

回答

3

TurboGears2中的config支持複雜的結構,例如您可以在myapp.option1myapp.option2等中聲明您的應用程序的選項。他們可以在您的應用程序中以tg.config['myapp.option1']tg.config.myapp.option1訪問。

這樣你就可以避免碰撞。

選項可以在您的development.iniconfig.app_cfg中設置。

例如,如果你把你的app_cfg

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

的FOOBAR字符串內將可以訪問來自tg.config.myapp.option1

注重的是base_config對象覆蓋從的.ini配置文件中加載選項。

相關問題