symfony 1.0 から 1.1へアップグレード(UPGRADE_TO_1_1)

このファイルは http://trac.symfony-project.org/browser/branches/1.2/UPGRADE_TO_1_1 の翻訳です。

注意

このページはUPGRADE_TO_1_1(日本語訳)の体裁を整え読みやすくした記事です。

このドキュメントではsymfony1.1での変更点とsymfony1.0系のプロジェクトをアップグレードするためには何をする必要があるかについて説明しています。

注意: symfony 1.1はPHP5.1より新しいものとのみ互換性があります。

アップグレード方法

プロジェクトをアップグレードする方法

  • SCM(バージョン管理システム）ツールを使っていない場合は、プロジェクトのバックアップをとっておいて下さい。symfonyはアップグレード中にファイルを置き換えるので（例えばフロンとコントローラー）、アップグレード後にあなたのカスタマイズ部分をマージするための手段が必要です。
  • プロジェクトルートにある`symfony`ファイルにある次の３行を
    PLAIN TEXT
    PHP:
    1. chdir(dirname(__FILE__));
    2. include('config/config.php');
    3. include($sf_symfony_data_dir.'/bin/symfony.php');

    以下に変更してください

    PLAIN TEXT
    PHP:
    1. chdir(dirname(__FILE__));
    2. require_once(dirname(__FILE__).'/config/ProjectConfiguration.class.php');
    3. $configuration = new ProjectConfiguration();
    4. include($configuration->getSymfonyLibDir().'/command/cli.php');

    また、symfonyのskeletonディレクトリからスケルトンファイルをコピーすることでも可能です。

    $ cp /path/to/symfony/lib/task/generator/skeleton/project/symfony symfony

  • `config/ProjectConfiguration.class.php`ファイルを以下の内容で作成してください。
    PLAIN TEXT
    PHP:
    1. <?php
    2. require_once '##SYMFONY_LIB_DIR##/autoload/sfCoreAutoload.class.php';
    3. sfCoreAutoload::register();
    4.  
    5. class ProjectConfiguration extends sfProjectConfiguration
    6. {
    7.   public function setup()
    8.   {
    9.   }
    10. }

    そして、`##SYMFONY_LIB_DIR##` をあなたの環境のsymfony1.1の`lib/`ディレクトリへのパスに書き換えてください。これでプロジェクトで使用されているsymfonyのバージョンを変更することができます。

    また、symfonyプロジェクトのskeletonディレクトリからスケルトンファイルをコピーすることでも可能です。

    $ cp /path/to/symfony/lib/task/generator/skeleton/project/config/ProjectConfiguration.class.php config/ProjectConfiguration.class.php

  • 自動でアップグレードを行うために、プロジェクトディレクトリから`project:upgrade1.1` タスクを実行します。
    PLAIN TEXT
    PHP:
    1. $ ./symfony project:upgrade1.1

    このタスクは副作用なく複数回繰り返して実行することができます。つまり、新しいバージョンのsymfony 1.1, beta / RC または最終的にリリースされたsymfony1.1へアップグレードする度に、このタスクを実行する必要があります。

  • もし、バリデーションやメール送信システムを新しいシステムにアップグレードする計画がないのであれば、互換性モードを`settings.yml`で有効にしなければなりません。
    PLAIN TEXT
    CSS:
    1. all:
    2.   .settings:
    3.     compat_10: on

    以下は互換性モードが有効になっているときの互換性の一覧です。（バンドルされている`sfCompat10Plugin`プラグインにあるもっと詳しい情報を参照してください。）

    • Zend Framework と ezComponentsブリッジ
    • sfProcessCache
    • バリデーションシステム(validate.yml, バリデータクラスなど)
    • フィルターに記入する
    • phpmailerを使用したsfMail

ここからは互換性のない変更点について説明します。

バッチスクリプト

バッチスクリプトの利用は廃止され、CLIタスクに代わりました。新しいCLIシステムは簡単に新しいsymfonyコマンドをプロジェクトに追加することができます。詳しくはドキュメントの16章を参照してください。
もし古いバッチスクリプトを動作させたいなら、各バッチスクリプトの最初の行をフロントコントローラーと同じよううに変更する必要があります。そのため以下の部分を

PLAIN TEXT
PHP:
  1. <?php
  2.     define('SF_ROOT_DIR',    realpath(dirname(__FILE__).'/..'));
  3.     define('SF_APP',         'frontend');
  4.     define('SF_ENVIRONMENT', 'prod');
  5.     define('SF_DEBUG',       false);
  6.  
  7.       require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');
  8.     // your batch code here

次のように変更しなければなりません。

PLAIN TEXT
PHP:
  1. <?php
  2.     require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
  3.     $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);
  4.     sfContext::createInstance($configuration);
  5.  
  6.     // your batch code here

データベース接続を初期化する必要があるなら、さらに以下の行を追加するだけです。

PLAIN TEXT
PHP:
  1. $databaseManager = new sfDatabaseManager($configuration);
  2.     $databaseManager->loadConfiguration();

Flash属性

Flash属性は`sfUser`によって直接管理されるようになります。新しい使い方は以下の通りです。

PLAIN TEXT
PHP:
  1. // action
  2. $this->getUser()->setFlash('notice', 'foo');
  3. $notice = $this->getUser()->getFlash('notice');

PLAIN TEXT
PHP:
  1. // template
  2. <?php $sf_user->hasFlash('notice'): ?>
  3. <?php echo $sf_user->getFlash('notice') ?>
  4. <?php endif; ?>

`filters.yml`にある`flash`項目は`sfFlashFilter`と同じく削除しなければなりません。

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

sfComponentにある廃止されたメソッド

次の`sfComponent`にあるメソッドは削除されました。

  • `->getPresentationFor()`
  • `->sendEmail()`

これらは`sfController`からアクセスできます。

PLAIN TEXT
PHP:
  1. // action
  2. $this->getController()->getPresentationFor(...);

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

シングルトン

sfI18N, sfRoutingそしてsfLoggerオブジェクトはファクトリメソッドパターンであり、シングルトンではありません。

もし、コードの中でこれらのオブジェクトをたった１つだけ取得したい場合は、`sfContext`から利用できます。

PLAIN TEXT
PHP:
  1. sfContext::getInstance()->getI18N()
  2. sfContext::getInstance()->getRouting()
  3. sfContext::getInstance()->getLogger()

ルーティング

以下は`factories.yml`にあるルーティングのための標準の設定です。

PLAIN TEXT
CSS:
  1. routing:
  2.   class: sfPatternRouting
  3.   param:
  4.     load_configuration: true

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

ロギング

以下は`factories.yml`にあるロギングのための標準の設定です。

PLAIN TEXT
CSS:
  1. logger:
  2.   class: sfAggregateLogger
  3.   param:
  4.     level: debug
  5.     loggers:
  6.       sf_web_debug:
  7.         class: sfWebDebugLogger
  8.         param:
  9.           condition: %SF_WEB_DEBUG%
  10.           xdebug_logging: true
  11.       sf_file_debug:
  12.         class: sfFileLogger
  13.         param:
  14.           file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log

`logging.yml`設定ファイルはもう使われません。代わりに、`factories.yml`でロギングの設定が行えます。

製品環境でロギングを無効にするためには、アプリケーションの`factories.yml`に変更を加えなければなりません。

PLAIN TEXT
CSS:
  1. prod:
  2.   logger:
  3.     class:   sfNoLogger
  4.     param:
  5.       level:   err
  6.       loggers: ~

`logging_enabled`設定が`settings.yml`に新しく存在しています。

この項目でも製品環境でロギングされないように設定することができます。

PLAIN TEXT
CSS:
  1. prod:
  2.   .settings:
  3.     logging_enabled: off

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

i18n

以下は`factories.yml`にあるi18nのための標準設定です。

PLAIN TEXT
CSS:
  1. i18n:
  2.   class: sfI18N
  3.   param:
  4.     source:              XLIFF
  5.     debug:               off
  6.     untranslated_prefix: "[T]"
  7.     untranslated_suffix: "[/T]"
  8.     cache:
  9.       class: sfFileCache
  10.       param:
  11.         automatic_cleaning_factor: 0
  12.         cache_dir:                 %SF_I18N_CACHE_DIR%
  13.         lifetime:                  86400
  14.         prefix:                    %SF_APP_DIR%

`i18n.yml`設定ファイルはもう使われません。代わりに、`factories.yml`でi18nについて設定することができます。

唯一の例外は`settings.yml`に今もある`default_culture`設定でi18nフレームワークに依存していません。

PLAIN TEXT
CSS:
  1. default_culture: en

もし、あなたのプロジェクトが特別な設定になっているのなら、現在の設定を`i18n.yml`から`factories.yml`に移動させ、上にあるように`settings.yml`にdefault_cultureの設定を追加しなければなりません。

キャッシュフレームワーク

`sfFunctionCache`クラスは`sfFileCache`クラスの拡張ではなくなりました。

現在は、キャッシュオブジェクトをコンストラクタに渡さなければなりません。

->call()への最初の引数はPHPが呼び出せるものでなければなりません。

`sfCache`設定パラメータの名前がアンダースコア形式の名前に変更されました。

  • automaticCleaningFactor -> automatic_cleaning_factor
  • cacheDir -> cache_dir

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

オートローディング

`settings.yml`にある`autoloading_function`設定はもう使われません。

あなたのアプリケーションにある設定クラスにautoloadingを登録できます。

新しい`sfAutoload::autoloadAgain()`メソッドのおかげで、プロジェクトにクラスを追加したり移動したりしてもキャッシュをクリアする必要がありません。このメソッドは自動的に変更点をみつけ、自動読み込みのためのキャッシュを更新します。

VERSIONファイル

lib/VERSION ファイルは削除されました。もし現在のsymfonyのバージョンを知りたい場合は、`SYMFONY_VERSION`定数を使うことができます。この定数は`autoload/sfCoreAutoload.class.php`で定義されます。

ルーティング

標準のルーティングのためのパラメータを注入するために、これからは`sf_routing_defaults`設定を使う代わりに`->setDefaultParameter()`メソッドを使うことができます。

PLAIN TEXT
PHP:
  1. $this->context->getRouting()->setDefaultParameter($key, $value);

I18N

symfonyのコアクラスは国際化された文字列を返しません。

PLAIN TEXT
PHP:
  1. <?php echo __($sf_request->getError('foo')) ?>

この動作は以下のメソッドと関数に代わりました。

PLAIN TEXT
PHP:
  1. sfWebRequest::getError()
  2. sfWebResponse::addMeta()

以下の(sfCompat10Pluginにある)ヘルパーでは、まだ国際化されたデータを返します。

PLAIN TEXT
PHP:
  1. form_error()
  2. include_metas()

`getGlobalMessageSource()`と`getGlobalMessageFormat()`メソッドはsfI18Nクラスから削除されました。それらは現在では`getMessageSource()`と`getMessageFormat()`に実装されています。

Logger

ロガーのプライオリティは現在では次のような定数になっています。

PLAIN TEXT
PHP:
  1. sfLogger::INFO

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

sfActionで廃止されたメソッド

以下の`sfAction`にあるメソッドは廃止され、`sf_compat_10`が`false`に設定されていたなら`sfConfigurationException`の例外を投げます。

  • `->validate()`
  • `->handleError()`

sfRequestで廃止されたメソッド

以下の`sfRequest`にあるメソッドは廃止され、`sf_compat_10`が`false`に設定されていたなら`sfConfigurationException`の例外を投げます。

  • `->getError()`
  • `->getErrors()`
  • `->getErrorNames()`
  • `->hasError()`
  • `->hasErrors()`
  • `->setError()`
  • `->setErrors()`
  • `->removeError()`

sfWebRequestで廃止されたメソッド

以下の`sfWebRequest`にあるメソッドは廃止され、`sf_compat_10`が`false`に設定されていたなら`sfConfigurationException`の例外を投げます。

  • `->getFile()`
  • `->getFileError()`
  • `->getFileName()`
  • `->getFileNames()`
  • `->getFilePath()`
  • `->getFileSize()`
  • `->getFileType()`
  • `->hasFile()`
  • `->hasFileError()`
  • `->hasFileErrors()`
  • `->hasFiles()`
  • `->getFileValue()`
  • `->getFileValues()`
  • `->getFileExtension()`
  • `->moveFile()`

`->initialize()` メソッド

ほとんどのsymfonyのコアクラスは`->initialize()`メソッドのおかげで初期化されます。

symfony1.1においては、このメソッドは自動的に`__construct()`で呼ばれます。そのため、あなた自身が呼び出す必要はありません。

設定ファイルの読み込み

コアクラスの中には`.yml`ファイルで設定できるものがあります。

Class Configuration file
`sfAction` `security.yml`
`sfAutoload` `autoload.yml`
`sfConfigCache` `config_handlers.yml`
`sfContext` `factories.yml`
`sfController` `generator.yml` and `module.yml`
`sfDatabaseManager` `databases.yml`
`sfFilterChain` `filters.yml`
`sfI18N` `i18n.yml`
`sfPatternRouting` `routing.yml`
`sfPHPView` `view.yml`
`sfViewCacheManager` `cache.yml`

symfony1.1では、``独立した``サブフレームワークのための設定ファイルの読み込みは重複したものを消したり、フレームワーク全体で必要とされていないサブフレームワークを再利用できるように`loadConfiguration()`メソッドに移動しました。

  • `sfDatabaseManager`
  • `sfI18N`
  • `sfPatternRouting`

そのため、例えば、バッチスクリプトでデータベースマネージャが必要であれば、次のようなコードから

PLAIN TEXT
PHP:
  1. $databaseManager = new sfDatabaseManager();
  2. $databaseManager->initialize();

以下のようなコードに書き換えなければなりません。

PLAIN TEXT
PHP:
  1. $configuration = ProjectConfiguration::getApplicationConfiguration($application, $env, true);
  2. $databaseManager = new sfDatabaseManager($configuration);
  3. $databaseManager->loadConfiguration();

`initialize()`の呼び出しはもはや必要ありません。(上記参照）

Web デバッグ

`filters.yml`にある`web_debug`項目は`sfWebDebugFilter`と同じく削除されました。Webデバグツールバーは現在ではレスポンスの中にリスナーによって注入されています。

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

セッションのタイムアウト

`sf_timeout`設定はもう使われません。セッションのタイムアウトを変更するためには、`settings.yml`の代わりに`factories.yml`を編集し、`user`部分のパラメータを変更しなければなりません。

PLAIN TEXT
CSS:
  1. all:
  2.   user:
  3.     class: myUser
  4.     param:
  5.       timeout:     1800     # session timeout in seconds

ルーティング設定

`sf_suffix`, `sf_default_module`　そして `sf_default_action`設定はもう使用されません。標準の接尾辞(サフィックス)、モジュール、アクションを変更するためには、`setting.yml`の代わりに`factories.yml`を編集し、`routing`部分を変更しなければなりません。

PLAIN TEXT
CSS:
  1. all:
  2.   routing:
  3.     class: sfPatternRouting
  4.     param:
  5.       load_configuration: true
  6.       suffix:             .       # Default suffix for generated URLs. If set to a single dot (.), no suffix is added. Possible values: .html, .php, and so on.
  7.           default_module:     default # Default module and action to be called when
  8.           default_action:     index   # A routing rule doesn't set it

`php.yml` 設定ファイル

`php.yml`設定は削除されました。

手動でチェックしなければならない設定項目は、`log_errors`という項目が`php.yml`で`on`になっているかです。

`php.yml`は`data/bin`にある`check_configuration.php`ユーティリティにとって代わりました。それはsymfonyが必要とする環境に反していないかどうかを確認します。どこからでも以下のようにして起動できます。

$ php /path/to/symfony/data/bin/check_configuration.php

コマンドラインからこのユーティリティを使うことができるとしても、PHPがCLI版とWEB版で異なるphp.iniを使うことができてしまうので、ウェブルートディレクトリにコピーし、ブラウザから起動することを強く推奨します。

`$sf_symfony_data_dir` の削除

symfony1.1では、`$sf_symfony_data_dir`は削除されました。全ての関連するファイルとディレクトリはsymfonyの`data`ディレクトリから`lib`ディレクトリに移動されました。

Old Location New Location
`data/config` `lib/config/config`
`data/i18n` `lib/i18n/data`
`data/skeleton` `lib/task/generator/skeleton`
`data/modules/default` `lib/controller/default`
`data/web/errors` `lib/exception/data`
`data/exception.*` `lib/exception/data`

symfonyのコアクラスはこれらの変更を考慮するようにアップグレードされました。

sfLoader

全ての`sfLoader`の静的なメソッド(`::getHelperDirs()`と`::loadHelpers()`は除く)は`sfProjectConfiguration`と`sfApplicationCOnfiguration`クラスに移動しました。

  • `sfProjectConfiguration`:
    • `->getGeneratorSkeletonDirs()`

    • `->getGeneratorTemplate()`
    • `->getGeneratorTemplateDirs()`
    • `->getModelDirs()`
  • `sfApplicationConfiguration`:
    • `->getControllerDirs()`

    • `->getTemplateDirs()`
    • `->getTemplateDir()`
    • `->getTemplatePath()`
    • `->getI18NGlobalDirs()`
    • `->getI18NDirs()`
    • `->getConfigPaths()`

sfCore

`sfCore`は削除されました。そしてこのコードは`sfProjectConfiguration`, `sfApplicationConfiguration`そして`sfContext`クラスに移動しました。

フロントコントローラー

全てのフロントコントローラーはアップグレードしなければなりません。SF_DEBUG, SF_APP, SF_ENVIRONMENTそしてSF_ROOT_DIRの定数はもうありません。もしこれらの定数が必要であれば、`sfConfig::get('')`を使ってください。

Old New
`SF_ROOT_DIR` `sfConfig::get('sf_root_dir')`
`SF_ENVIRONMENT` `sfConfig::get('sf_environment')`
`SF_APP` `sfConfig::get('sf_app')`
`SF_DEBUG` `sfConfig::get('sf_debug')`

これらの変更作業は`project:upgrade1.1`タスクがあなたに代わって全て行ってくれます。

もし、カスタマイズを行っているならば、タスクを実行すると警告が表示され、自動的にアップグレードできないでしょう。また、symfony: /path/to/symfony/lib/task/generator/skeleton/app/web/index.phpから標準のスケルトンをコピーすることができます。

config.php

全ての`config.php`ファイルは削除されました。`ProjectConfiguration`クラスとアプリケーションの設定クラスに置き換えられました。

`config.php`にカスタマイズを行っている場合は、新しいクラスに移動させなければなりません。

ディレクトリ構造

全ての`_dir_name`で終わっている`sfConfig`定数は削除されました。

Cache keys

`sfViewCacheManager::removePattern()`と`sfToolkit::clearGlob()`は一度に複数のキャッシュ部分を削除するためには動作しなくなりました。しかし、`sfViewCacheManager::remove()`は内部URIをワイルドカードを用いて受け入れることができるようになっています。

そのために、次のようなコードは

PLAIN TEXT
PHP:
  1. $cacheManager->removePattern('*/all/user/show/id/*');

以下のように書き換えることができます。

PLAIN TEXT
PHP:
  1. $cacheManager->remove('user/show?id=*', '*', 'all');

また、パーシャルや、テンプレートごとの異なるパーシャルに対しても動作します。そのため以下のようなコードは

PLAIN TEXT
PHP:
  1. $cacheManager->removePattern('/sf_cache_partial/user/_my_partial/sf_cache_key/*');

以下のように書き換えることができます

PLAIN TEXT
PHP:
  1. $cacheManager->remove('@sf_cache_partial?module=user&action=_my_partial&sf_cache_key=*');

そして、最大の利点は `sfFileCache`だけでなく *どんな* キャッシュファクトリでも`glob`スタイルでURIを消去することができることです。

レイアウト

アクションテンプレートの変数はレイアウト内では利用できません。これはレイアウトは**グローバル**な変数(sf_で始まる全ての変数)と、`tempalte.filter_parameters`イベントを通して登録されている変数にのみアクセスすることができるということです。

アップグレードの方法については以下のwikiを参照してください。
http://trac.symfony-project.com/wiki/Symfony11LayoutUpgrade

タスク

symfonyコマンドラインタスクの名前が変更されました。新しい名前空間の構文が使われるようになりました。古いsymfonyタスク名はまだ動作します。そしてそれらは新しいタスク名のエイリアスにすぎません。以下に変更した名前を表にまとめてあります。

Old task name New task name
clear-cache cache:clear||
clear-controllers project:clear-controllers
disable project:disable
downgrade [Not implemented]
enable project:enable
fix-perms project:permissions
freeze project:freeze
init-app generate:app
init-batch [Not implemented]
init-controller [Not implemented]
init-module generate:module
init-project generate:project
log-purge log:clear
log-rotate log:rotate
plugin-install plugin:install
plugin-list plugin:list
plugin-uninstall plugin:uninstall
plugin-upgrade plugin:upgrade
propel-build-all propel:build-all
propel-build-all-load propel:build-all-load
propel-build-db propel:build-db
propel-build-model propel:build-model
propel-build-schema propel:build-schema
propel-build-sql propel:build-sql
propel-convert-xml-schema propel:schema-to-yml
propel-convert-yml-schema propel:schema-to-xml
propel-dump-data propel:data-dump
propel-generate-crud propel:generate-crud
propel-init-admin propel:init-admin
propel-init-crud [Not implemented]
propel-insert-sql propel:insert-sql
propel-load-data propel:data-load
sync project:deploy
test-all test:all
test-functional test:functional
test-unit test:unit
unfreeze project:unfreeze
upgrade project:freeze

以前ように、利用可能なタスクのリストを表示させたいなら、引数無しで`symfony`コマンドを呼ぶだけです。

> php symfony

早期に適用しようとしている開発者へ

もし、プロジェクトをアップグレードさせて、`lib/Projectconfiguratioun.class.php`ファイルが存在するならば、`project:upgrade1.1`タスクを実行できるようにする前に手動でプロジェクトをアップグレードする必要があります。

以下に手順を示します。

  • `lib/ProjectConfiguration.class.php` を `config/ProjectConfiguration.class.php`　に移動します。
  • 必要があれば、`config/ProjectConfiguration.class.php`にあるsymfonyへのパスを変更します。
  • 全てのアプリケーションの設定クラス(`lib/$APP_NAME$Configuration.class.php`)を`apps/$APP_NAME$/config/`ディレクトリに移動します。
  • 全てのアプリケーション設定クラスにある`require_once dirname(__FILE__).'/ProjectConfiguration.class.php';`を削除します。
  • メインの`symfony`スクリプトにある`ProjectConfiguration.class.php`の位置を`config/`に変更します。
  • フロントコントローラを次のように変更します。
PLAIN TEXT
PHP:
  1. <?php
  2.  
  3. require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php');
  4.  
  5. $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', true);
  6. sfContext::createInstance($configuration)->dispatch();

これで`project:upgrade1.1`スクリプトを実行し、アップグレードすることができます。