1

Django のバックグラウンドを持つ私は、フレームワークの構成のみではなく、アプリ層の構成に適した (そして意図された) 構成メカニズムを提供するフレームワークに慣れています。

TurboGears 2.x テンプレートには<app_module>.config.app_cfgモジュールが含まれており、展開の ini ファイルでオーバーライドできます。ただし、これは「TG2固有の」設定用として明示的に文書化されており、アプリ用に思いついた構成エントリが追加された新しい設定と衝突するのを防ぐような命名規則や名前空間メカニズムが文書化されていません将来的に他のフレームワーク コンポーネントに。

TurboGears 2.x は、TG2 自体に固有のものではなく、TG2 で構築されたアプリケーションの構成を管理するためのメカニズムを提供しますか、または TG2 開発者 (Paste など) に認められたベスト プラクティスのセットに含まれますか? 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

object は、 .ini構成ファイルbase_configからロードされたオプションを上書きすることに注意してください。

于 2012-03-14T21:45:45.137 に答える