フレームワークを利用する大きな利点の1つは複数のプロジェクトでまたがった一貫した構造です。 すべてのプロジェクトは同じコーディング規約および同じディレクトリ構造を共有します。 この構造によって同じプロジェクトで同時に作業できます。 しかし開発されたアプリケーションのメンテナンス可能性も強化されます。 あなたが最初に開発をしなかったsymfonyプロジェクトをメンテナンスするように誰かに頼まれたときに、すべてのファイルがどこに保存されているのか理解しているのですぐにハックを始めることができます。
しかし時には、symfonyによって提供されたディレクトリ構造をカスタマイズできることが必要です。2つのまったく異なる例を取り上げてみましょう。
最初に、共用ホスト環境で、Web公開ディレクトリのルートがpublic_html
という名前の共用ホスト環境でsymfonyのプロジェクトをホストする場合を考えてみましょう。
ProjectConfiguration
クラスを編集することで、デフォルトのWeb公開ディレクトリをweb
からpublic_html
に変更することはとても簡単です:
// config/ProjectConfiguration.class.php class ProjectConfiguration extends sfProjectConfiguration { public function setup() { $this->setWebDir($this->getRootDir().'/../public_html'); } }
別の例を取り上げてみましょう。
あなたのsymfonyプロジェクトが厳しいセキュリティルールを持つ大企業でホストされているとします。
そしていくつかの特定のディレクトリ(たとえば/tmp
)以外ではアプリケーションはディスクに書き込みできません。
symfonyは2つのディレクトリ(cache
とlog
)のみに書き込みするので、これらのディレクトリを/tmp
の下に設置するためにProjectConfiguration
クラスを再び更新するのはとても簡単です:
// config/ProjectConfiguration.class.php class ProjectConfiguration extends sfProjectConfiguration { public function setup() { $this->setCacheDir('/tmp/myproject/cache'); $this->setLogDir('/tmp/myproject/log'); } }
setCacheDir()
メソッドは定数sf_cache_dir
を変更するだけでなくキャッシュに関連したすべての定数: sf_app_base_cache_dir
、sf_app_cache_dir
、sf_template_cache_dir
、sf_i18n_cache_dir
、sf_config_cache_dir
、sf_test_cache_dir
とsf_module_cache_dir
も変更します。
大事なことを言い忘れていました。 設定クラスはsymfony CLIにも使われるので、これらすべてのカスタマイズはsymfonyに搭載されたタスクおよびあなた独自のタスクにも有効です。
symfony 1.1の新しい設定クラスのおかげで、フレームワークの設定作業はとても楽になりました。
This work is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License license.