The symfony Cookbook

フレームワークを利用する大きな利点の1つは複数のプロジェクトでまたがった一貫した構造です。すべてのプロジェクトは同じコーディング規約および同じディレクトリ構造を共有します。この構造によって同じプロジェクトで同時に作業できます。しかし開発されたアプリケーションのメンテナンス可能性も強化されます。あなたが最初に開発をしなかったsymfonyプロジェクトをメンテナンスするように誰かに頼まれたときに、すべてのファイルがどこに保存されているのか理解しているのですぐにハックを始めることができます。

しかし時には、symfonyによって提供されたディレクトリ構造をカスタマイズできることが必要です。2つのまったく異なる例を取り上げてみましょう。

最初に、共用ホスト環境で、web rootディレクトリがpublic_htmlという名前の共用ホスト環境でsymfonyのプロジェクトをホストする場合を考えてみましょう。ProjectConfigurationクラスを編集することで、デフォルトのweb rootディレクトリを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の新しい設定クラスのおかげで、フレームワークの設定作業はとても楽になりました。