TurboGears 2.xのアプリケーション層の設定名前空間

Question

Djangoの背景から来て、フレームワーク設定ではなくアプリケーション層の設定に適した設定メカニズムを提供するフレームワークに慣れています。

TurboGears 2.xテンプレートには、<app_module>.config.app_cfgモジュールが含まれています。このモジュールは、展開用のiniファイルで上書きできます。しかし、これは「TG2固有の」設定として明示的に記述されています。私は、新しい設定が追加されたときに私のアプリが思いつく設定エントリを妨げるような名前付け規則や名前空間の仕組みは何も表示されません将来他のフレームワークコンポーネントに提供することができます。

TurboGears 2.xでは、TG2開発者のためのベストプラクティスとして、TG2自体に固有のものではなく、TG2上に構築されたアプリケーションの構成を管理するメカニズムが含まれていますか？ TG2構成メカニズムを再利用することが従来的である場合、構成名前空間管理には何らかの慣習が認められていますか？

Answer 1

TurboGears2のconfigは、複雑な構造をサポートしています。例えば、アプリケーションのオプションをmyapp.option1myapp.option2のように宣言することができます。アプリケーション内では、tg.config['myapp.option1']とtg.config.myapp.option1の両方でアクセスできます。

この方法で、衝突を回避できます。

オプションは、development.iniとconfig.app_cfgの両方に設定できます。例えば

あなたapp_cfg

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

の内側に置く場合は、FOOBAR文字列がbase_configオブジェクトがの.ini構成ファイルからロードされたオプションを上書きすることtg.config.myapp.option1

注意を払うからアクセスできるようになります。