アンカーしたかったのですが、habraparserは:(を許可しません
Zend_Configとセクション
Zend Frameworkの公式ドキュメントでは、構成ファイルをいくつかのセクションに分割することを推奨しています。各セクションは、プロジェクトが動作するさまざまな環境を担当します。
同時に、構成の1つのセクションは別のセクションを継承し、変更する必要があるパラメーターのみをオーバーライドできます。
一見、この考えは理にかなっているように見えますが、このアプローチのいくつかの制限に遭遇しました...
ドキュメントの構成ファイルの例を次に示します。
; Production site configuration data
[production]
webhost = www.example.com
database.adapter = pdo_mysql
database.params.host = db.example.com
database.params.username = dbuser
database.params.password = secret
database.params.dbname = dbname
; Staging site configuration data inherits from production and
; overrides values as necessary
[staging : production]
database.params.host = dev.example.com
database.params.username = devuser
database.params.password = devsecret
そのため、本番セクションではパラメータの完全なリストを定義し、ステージングセクションではデータベースにアクセスするためのいくつかのパラメータのみを再定義します。
区分的アプローチの制限
実際には、第一に、一般的な構成で本番データベースにアクセスするためのパスワードを保存することは良い考えではありません。第二に、この形式の構成は、GitやSubversionのようなメインストリームバージョン管理システム（SLE）に保存することは文字通り不可能です。
プロジェクトに参加している各開発者は、独自のローカル設定をステージングセクションに喜んでコミットします。せいぜい、ステージングから継承して独自のセクションを作成します。
これはすべて、リポジトリ内の設定の混乱と無駄な成長につながります。
ハード通貨で設定を保存するための従来のスクリプト
一般的な構成が開発者の個人設定で詰まらないように、通常config.default.iniまたはconfig.ini.defaultのような名前でリポジトリに配置され、作業ディレクトリの各開発者がconfig.iniと呼ばれるそのコピーを作成します。無視されたファイルのリストにSLEが追加されます。
ここでは幸福のようです：デフォルトの設定をコピーしたら、そこの個人設定で運転し、それを永遠に忘れました...
どんなに！
1か月が経過し、開発者の1人がkofigに有用な（またはそうでない）設定を追加することにしました。
彼はこの設定をデフォルトの構成に静かにコミットし、プロジェクトコードに変更を加えます。この設定が構成で指定されていない場合、プロジェクトコードは完全に壊れ、達成感を持って休暇を取ります...
翌日に何が起こると思いますか？ :)
構成を変更した開発者が企業のメーリングリストに「ローカルconfig.iniを更新してください」という件名で手紙を送信することを忘れず、この手紙を受け取った開発者がそれを読んで、重要なことに、実現して実行することを忘れないという最も理想的な状況を考慮しても時間の経過とともに設定のサイズが大きくなるだけで、すべての変更を手動で追跡することはできないため、それらはすべて、diffなどのユーティリティを使用してローカル設定を手動で更新する必要があります
私に起こった簡単なアイデア
Zend_Configクラスを拡張し、その中に設定の継承を実装することにしました。
しかし、彼のコードを調べるとすぐに、継承に必要なものがすべて最初に組み込まれていることにすぐに気付きました。
そのため、ここでは継承を使用して構成を使用する例を示します。
一般的なプロジェクト設定はconfig.common.iniです：
[production]
resources.db.adapter = "PDO_MySQL"
resources.db.params.dbname = "system"
resources.db.params.username = "root"
resources.db.params.password = ""
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
私の個人的な構成はconfig.iniです：
[production]
[development : production]
resources.db.params.dbname = "system_laggyluke"
resources.db.params.username = "laggyluke"
resources.db.params.password = "mySecretPassword"
configsの継承を実装する例 ：
//
// true , read-only
$config = new Zend_Config_Ini( 'config.common.ini' , 'development' , true );
// ,
if (file_exists( 'config.ini' )) {
// - ...
$configCustom = new Zend_Config_Ini( 'config.ini' , 'development' );
// ...
$config->merge($configCustom);
}
// read-only,
$config->setReadOnly();
* This source code was highlighted with Source Code Highlighter .
一般的なconfig.common.ini構成はハード通貨で保存され、それに追加された新しい設定はすべてすべての開発者にすぐに適用されます。 同時に、各開発者は個人のconfig.iniの設定を上書きできますが、これはSLEによって無視されます。
このアプローチのマイナス面のうち、個人的な構成では、一般的な構成で宣言されたすべてのセクションをリストする必要があることに注意してください。 しかし、個人的には、これは特定の問題を構成するものではありません。なぜなら、それらのリストはめったに変更されず、ほとんどの場合変更されないからです。
もちろん、この考えは新しいものではなく、そのようなアプローチが既にどこかで実現していることを正確に覚えています。
このような便利な手法が公式ドキュメントに記載されていないことに驚いただけです。つまり、多くの開発者には知られていない可能性があります。
UPD。
stfalconは、バージョン1.8.2以降、 同様の機能がZend_Applicationに既に実装されていることを示唆しました。