Development

Changeset 27631

You must first sign up to be able to contribute.

Changeset 27631

Show
Ignore:
Timestamp:
02/07/10 11:08:22 (3 years ago)
Author:
masaki
Message:

[1.4][doc-ja] updated the tutorials

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • doc/branches/1.4/tutorial/ja/deprecated.markdown

    r25643 r27631  
    1 1.3の廃止予定および削除される機能 
    2 ================================ 
     11.3 での廃止予定および削除される機能 
     2=================================== 
    33 
    44このドキュメントでは symfony 1.3 で廃止予定もしくは削除されるすべての設定、クラス、メソッド、関数とタスクの一覧を示します。  
    …… 
    99次のコアプラグインは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 
    1010 
    11   * `sfCompat10Plugin`: このプラグインを廃止予定にすることで、動作するためにこのプラグインに依存するほかのすべての要素も廃止予定にします (1.0の admin ジェネレーターとフォームシステム)。これは `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される1.0の admin ジェネレーターのデフォルトテーマも含みます。 
     11  * `sfCompat10Plugin`: このプラグインを廃止予定になることで、動作するためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0 のアドミンジェネレーターとフォームシステム)。これは `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される 1.0 のアドミンジェネレーターのデフォルトテーマも含まれます。 
    1212 
    1313  * `sfProtoculousPlugin`: このプラグインによって提供されるヘルパーは控えめな JavaScript をサポートしないので、今後は使うべきではありません。 
    …… 
    1818次のメソッドと関数は symfony 1.3 かそれ以前で廃止予定になり、symfony 1.4 で削除されます: 
    1919 
    20   * `sfToolkit::getTmpDir()`: このメソッドのすべての呼び出しを `sys_get_temp_dir()` に置き換えます。 
     20  * `sfToolkit::getTmpDir()`: このメソッドのすべての呼び出しは `sys_get_temp_dir()` に置き換えます。 
    2121 
    2222  * `sfValidatorBase::setInvalidMessage()`: 新しい `sfValidatorBase::setDefaultMessage()` メソッドの呼び出しに置き換えます。 
    …… 
    2626  * `sfTesterResponse::contains()`: より強力な `matches()` メソッドを使うことができます 
    2727 
    28   * `sfTestFunctionalBase` の次のメソッド: `isRedirected()`、`isStatusCode()`、`responseContains()`、`isRequestParameter()`、`isResponseHeader()`、`isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは1.2以降で廃止予定になり、テスタークラスに置き換えられました。 
     28  * `sfTestFunctionalBase` の次のメソッド: `isRedirected()`、`isStatusCode()`、`responseContains()`、`isRequestParameter()`、`isResponseHeader()`、`isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換えられました。 
    2929 
    3030  * `sfFilesystem::sh()`: このメソッドのすべての呼び出しを新しい `sfFilesystem::execute()` メソッドの呼び出しに置き換えます。このメソッドの戻り値は `stdout` 出力と `stderr` 出力で構成される配列であることに注意してください。 
    3131 
    32   * `sfAction::getDefaultView()`、`sfAction::handleError()`、`sfAction::validate()`: これらのメソッドは symfony 1.1 で廃止になり、またあまり便利なものではありませんでした。symfony 1.1 に関して、`compat_10` 設定を `on` にセットする必要があります。 
     32  * `sfAction::getDefaultView()`、`sfAction::handleError()`、`sfAction::validate()`: これらのメソッドは symfony 1.1 で廃止予定になり、またあまり便利なものではありませんでした。symfony 1.1 に関して、`compat_10` 設定を `on` にセットする必要があります。 
    3333 
    3434  * `sfComponent::debugMessage()`: 代わりに `log_message()` ヘルパーを使います。 
    …… 
    6969  * `sfNoRouting` と `sfPathInfoRouting` 
    7070 
    71   * `sfRichTextEditor`、`sfRichTextEditorFCK` と `sfRichTextEditorTinyMCE`: これらはウィジェットシステムに置き換えられました(下記の"ヘルパー"の節を参照)。 
     71  * `sfRichTextEditor`、`sfRichTextEditorFCK` と `sfRichTextEditorTinyMCE`: これらはウィジェットシステムに置き換えられました (下記の"ヘルパー"のセクションを参照)。 
    7272 
    73   * `sfCrudGenerator`、`sfAdminGenerator`、`sfPropelCrudGenerator`、`sfPropelAdminGenerator`: これらのクラスは 1.0の admin ジェネレーターで使われていました。 
     73  * `sfCrudGenerator`、`sfAdminGenerator`、`sfPropelCrudGenerator`、`sfPropelAdminGenerator`: これらのクラスは 1.0のアドミンジェネレーターで使われていました。 
    7474 
    75   * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは1.0のフォームシステムで使われていました。 
     75  * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは 1.0 のフォームシステムで使われていました。 
    7676 
    77   * `sfLoader`: "メソッドと関数"の節を参照。 
     77  * `sfLoader`: "メソッドと関数"のセクションを参照。 
    7878 
    7979  * `sfConsoleRequest`、`sfConsoleResponse`、`sfConsoleController` 
    …… 
    8383  * `sfWidgetFormI18nSelectLanguage`、`sfWidgetFormI18nSelectCurrency` と `sfWidgetFormI18nSelectCountry`: 対応する `Choice` ウィジェットを使います (対応するのは順に `sfWidgetFormI18nChoiceLanguage`、`sfWidgetFormI18nChoiceCurrency` と `sfWidgetFormI18nChoiceCountry`)。カスタマイズできることを除いて、これらはまったく同じように動作します。 
    8484 
    85   * `SfExtensionObjectBuilder`、`SfExtensionPeerBuilder`、`SfMultiExtendObjectBuilder`、`SfNestedSetBuilder`、`SfNestedSetPeerBuilder`、`SfObjectBuilder`、`SfPeerBuilder`: カスタムの Propel ビルダークラスは Propel 1.4 の新しいビヘイビアシステムに移植されました。 
     85  * `SfExtensionObjectBuilder`、`SfExtensionPeerBuilder`、`SfMultiExtendObjectBuilder`、`SfNestedSetBuilder`、`SfNestedSetPeerBuilder`、`SfObjectBuilder`、`SfPeerBuilder`: Propel のカスタムビルダークラスは Propel 1.4 の新しいビヘイビアシステムに移植されました。 
    8686 
    8787次のクラスは symfony 1.3 で削除されます: 
    8888 
    89   * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は "プロジェクトを1.2から1.3/1.4にアップグレードする"のチュートリアルの"共通フィルターの削除"を参照してください。 
     89  * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は "プロジェクトを 1.2 から 1.3/1.4 にアップグレードする"のチュートリアルの"共通フィルターの削除"を参照してください。 
    9090 
    9191ヘルパー 
    …… 
    9494次のヘルパーグループは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 
    9595 
    96   * `sfCompat10Plugin` によって提供される1.0フォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object`と`Validation` 
     96  * `sfCompat10Plugin` によって提供される 1.0 フォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` 
    9797 
    9898`form_tag()` ヘルパーは `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4 でも利用加能です。 
    9999 
    100 PHP のインクルードパスからヘルパーをロードする機能は1.3 で廃止予定になり1.4で削除されました。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれかひとつに設置しなければなりません。 
     100PHP のインクルードパスからヘルパーをロードする機能は 1.3 で廃止予定になり 1.4 で削除されました。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか 1 つに設置しなければなりません。 
    101101 
    102102設定 
    …… 
    105105次の設定 (`settings.yml` 設定で管理される) は symfony 1.3 から削除されました: 
    106106 
    107   * `check_symfony_version`: この設定は symfony のバージョンが変更される場合にキャッシュの自動クリーニングを可能にするために数年前に導入されました。これは主にすべての顧客のあいだで symfony のバージョンが共有される共用ホスティングのコンフィギュレーションに便利でした。symfony 1.1 以降ではバッドプラクティスです (プロジェクトごとに symfony のバージョンを埋め込む必要がある)、設定は意味をなしません。さらに、この設定が `on` にセットされている場合、ファイルのコンテンツを得る必要があるときに、それぞれのリクエストに小さなオーバーヘッドを追加します。 
     107  * `check_symfony_version`: この設定は symfony のバージョンが変更される場合にキャッシュの自動クリーニングを可能にするために数年前に導入されました。これは主にすべての顧客のあいだで symfony のバージョンが共有される共用ホスティングのコンフィギュレーションに便利でした。symfony 1.1 以降ではバッドプラクティスですので (プロジェクトごとに symfony のバージョンを埋め込む必要がある)、設定は無意味です。さらに、この設定が `on` にセットされている場合、ファイルのコンテンツを得る必要があるときに、それぞれのリクエストに小さなオーバーヘッドを追加します。 
    108108 
    109   * `max_forwards`: この設定は symfony が例外を投げる前に許容されるフォワードの最大回数をコントロールします。これを設定可能にする値はありません。5回より多くのフォワードが必要な場合、問題の認識とパフォーマンスの両方で問題があります。 
     109  * `max_forwards`: この設定は symfony が例外を投げる前に許容されるフォワードの最大回数をコントロールします。これを設定可能にする値はありません。5 回より多くのフォワードが必要な場合、問題の認識とパフォーマンスの両方で問題があります。 
    110110 
    111   * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善として導入され、この設定はビューキャッシュのために遅延キャッシュキージェネレーションを有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも呼び出される `sfViewCacheManager::isCacheable()` に頼る人もいました。symfony 1.3 に関しては、ふるまいは `sf_lazy_cache_key` が `true` にセットされる場合と同じになります。 
     111  * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善として導入され、この設定はビューキャッシュのために遅延キャッシュキージェネレーションを有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも呼び出される `sfViewCacheManager::isCacheable()` に頼るひともいました。symfony 1.3 に関しては、ふるまいは `sf_lazy_cache_key` が `true` にセットされる場合と同じになります。 
    112112 
    113   * `strip_comments`: `strip_comments` は PHP 5.0.x バージョンのトークナイザーのバグが原因のコメントのストリッピングを無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかったとき、メモリーの大量消費を避けるためにも使われました。最初の問題は PHP の最小バージョンが5.2なので関係なくなっており2番目の問題はコメントのストリッピング機能をシミュレートした正規表現を削除することですでに修正されています。 
     113  * `strip_comments`: `strip_comments` は PHP 5.0.x バージョンのトークナイザーのバグが原因のコメントのストリッピング機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかったとき、メモリーの大量消費を避けるためにも使われました。最初の問題は PHP の最小バージョンが 5.2 なので関係なくなっており 2 番目の問題はコメントのストリッピング機能をシミュレートした正規表現を削除することですでに修正されています。 
    114114 
    115115  * `lazy_routes_deserialize`: このオプションはもう必要ありません。 
    …… 
    121121  * `validation_error_prefix`、`validation_error_suffix`、`validation_error_class`、`validation_error_id_prefix`: これらの設定は Validation ヘルパーグループによって使われ、symfony 1.3 で廃止予定です。 
    122122 
    123   * `is_internal` (`module.yml`): `is_internal` フラグはブラウザーからアクションが呼び出されるのを防止するために使われました。これは symfony 1.0 でメール送信を保護するために追加されました。メールのサポートはこのトリックを必要としなくなったので、このフラグは削除され symfony コアではチェックされません。 
     123  * `is_internal` (`module.yml`): `is_internal` フラグはブラウザーからアクションが呼び出されるのを防ぐために使われました。これは symfony 1.0 でメール送信を保護するために追加されました。メールのサポートはこのトリックを必要としなくなったので、このフラグは削除され symfony コアではチェックされません。 
    124124 
    125125タスク 
    …… 
    128128次のタスクは symfony 1.3 で削除されました: 
    129129 
    130   * `project:freeze` と `project:unfreeze`: これらのタスクはプロジェクトによって使われる symfony のバージョンをプロジェクト自身の内部に埋め込むために使われました。これらはもはや必要ありません。長期間をかけて symfony をプロジェクトに埋め込むのがベストプラクティスになったからです。さらに、あるバージョンの symfony を別のバージョンに切り替える作業は本当に単純で必要なのは `ProjectConfiguration` クラスへのパスを変更することだけです。 symfony を手作業で埋め込むのもとても単純で symfony のディレクトリ全体をプロジェクトのどこかにコピーすることだけ必要です (`lib/vendor/symfony/`が推奨されます)。 
     130  * `project:freeze` と `project:unfreeze`: これらのタスクはプロジェクトによって使われる symfony のバージョンをプロジェクト自身の内部に埋め込むために使われました。これらはもはや必要ありません。長期間をかけて symfony をプロジェクトに埋め込むのがベストプラクティスになったからです。さらに、あるバージョンの symfony を別のバージョンに切り替える作業は本当に単純で必要なのは `ProjectConfiguration` クラスへのパスを変更することだけです。symfony を手作業で埋め込むのもとても単純で symfony のディレクトリ全体をプロジェクトのどこかにコピーすることだけ必要です (`lib/vendor/symfony/` が推奨されます)。 
    131131 
    132132次のタスクは symfony 1.3 で廃止予定で、symfony 1.4 で削除されます: 
    …… 
    134134  * symfony 1.0 のすべてのタスクのエイリアス 
    135135 
    136   * `propel:init-admin`: このタスクは symfony 1.0 の admin ジェネレーターモジュールを生成しました。 
     136  * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレーターモジュールを生成しました。 
    137137 
    138138次の Doctrine タスクは `doctrine:build` にマージされ symfony 1.4 で削除されます: 
    …… 
    162162プロジェクトのルートの `doc/` ディレクトリは生成されなくなりました。symfony 自身でも使われていないからです。そして関連する `sf_doc_dir` も削除されました。 
    163163 
    164 `sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、 1.3 で廃止予定になり 1.4 で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。 
     164`sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、1.3 で廃止予定になり 1.4 で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。 
    165165 
    166166symfony のすべての `Base*` クラスは `abstract` とマークされていません。 

  • doc/branches/1.4/tutorial/ja/upgrade.markdown

    r25664 r27631  
    1 プロジェクトを1.2から1.3/1.4にアップグレードする 
    2 =============================================== 
    3  
    4 このドキュメントでは symfony 1.3/1.4 で行われた変更と1.2プロジェクトをアップグレードするために必要な作業を説明します。 
    5  
    6 symfony 1.3 で変更/追加された機能の詳細を知りたければ、[「symfony 1.3/1.4 の新しい機能」](http://www.symfony-project.org/tutorial/1_4/ja/whats-new)のチュートリアルをご覧ください。 
     1プロジェクトを 1.2 から 1.3/1.4 にアップグレードする 
     2=================================================== 
     3 
     4このドキュメントでは symfony 1.3/1.4 で行われた変更と 1.2 プロジェクトをアップグレードするために必要な作業を説明します。 
     5 
     6symfony 1.3 で変更または追加された機能の詳細を知りたければ、[「symfony 1.3/1.4 の新しい機能」](http://www.symfony-project.org/tutorial/1_4/ja/whats-new)のチュートリアルをご覧ください。 
    77 
    88>**CAUTION** 
    9 >symfony 1.3/1.4 は PHP 5.2.4 とそれ以降と互換性があります。PHP 5.2.0 から5.2.3までとも動作するかもしれませんが、保証はありません。 
     9>symfony 1.3/1.4 は PHP 5.2.4 とそれ以降と互換性があります。PHP 5.2.0 から 5.2.3 までとも動作するかもしれませんが、保証はありません。 
    1010 
    1111symfony 1.4 にアップグレードする 
    1212------------------------------- 
    1313 
    14 (すべての廃止予定の機能が取り除かれている以外) symfony 1.4は symfony 1.3 と同じなので、このバージョンにアップグレードするタスクはありません。1.4にアップグレードするには、最初に1.3にアップグレードしてから1.4リリースに切り替えなければなりません。 
    15  
    16 1.4にアップグレードする前に、`project:validate` タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます: 
     14(すべての廃止予定の機能が取り除かれていること以外) symfony 1.4 は symfony 1.3 と同じなので、このバージョンにアップグレードするタスクはありません。1.4にアップグレードするには、最初に 1.3 にアップグレードしてから1.4リリースに切り替えなければなりません。 
     15 
     161.4 にアップグレードする前に、`project:validate` タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます: 
    1717 
    1818    $ php symfony project:validate 
    …… 
    2020このタスクは symfony 1.4 に切り替える前に変更する必要のあるすべてのファイルの一覧を表示します。 
    2121 
    22 このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、これはすべてを検出できないので、これは起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。"1.3の廃止予定および削除される機能"のチュートリアルも注意深く読む必要があります。 
     22このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、これはすべてを検出できないので、これは起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。「1.3 の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。 
    2323 
    2424>**NOTE** 
    25 >`sfCompat10Plugin` と `sfProtoculousPlugin` は1.4から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。 
     25>`sfCompat10Plugin` と `sfProtoculousPlugin` は 1.4 から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。 
    2626 
    2727symfony 1.3 にアップグレードするには？ 
    …… 
    3434  * SCMツールを使わない場合、かならずプロジェクトのバックアップを行います。 
    3535 
    36   * symfony を1.3にアップグレードします。 
    37  
    38   * プラグインを1.3バージョンにアップグレードします。 
     36  * symfony を 1.3 にアップグレードします。 
     37 
     38  * プラグインを 1.3 対応のものにアップグレードします。 
    3939 
    4040  * 自動アップグレードを実行するためにプロジェクトディレクトリから `project:upgrade1.3` タスクを立ち上げます: 
    …… 
    4242        $ php symfony project:upgrade1.3 
    4343 
    44     このタスクは副作用なしで複数回立ち上げることができます。新しい symfony 1.3ベータ/RC もしくは最終版にアップグレードするたびに、このタスクを立ち上げなければなりません。 
     44    このタスクは副作用なしで複数回立ち上げることができます。新しい symfony 1.3 beta/RC もしくは最終版にアップグレードするたびに、このタスクを立ち上げなければなりません。 
    4545 
    4646  * 下記で記述される変更のために、モデルとフォームをリビルドする必要があります: 
    …… 
    5656        $ php symfony cache:clear 
    5757 
    58 残りのセクションはsymfony 1.3 で行われなんらかのアップグレード (自動もしくはそうではない) が必要な主要な変更を説明します。 
     58残りのセクションは symfony 1.3 で行われなんらかのアップグレード (自動もしくはそうではない) が必要な主要な変更を説明します。 
    5959 
    6060廃止予定 
    6161-------- 
    6262 
    63 symfony 1.3 を開発している間に、いくつかの設定、クラス、メソッド、関数とタスクを廃止予定にするもしくは削除してきました。詳細な情報は["1.3の廃止予定および削除される機能"](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。 
     63symfony 1.3 を開発している間に、いくつかの設定、クラス、メソッド、関数とタスクを廃止予定にするもしくは削除してきました。詳細な情報は[「1.3での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。 
    6464 
    6565オートロード機能 
    6666---------------- 
    6767 
    68 symfony 1.3 に関しては、`lib/vendor/` ディレクトリの下にあるファイルはもはやオートロードされません。`lib/vendor/` サブディレクトリをオートロードしたい場合、新しいエントリーをアプリケーションの `autoload.yml` 設定ファイルに追加します: 
     68symfony 1.3 に関しては、`lib/vendor/` ディレクトリの下にあるファイルはもはやオートロードされません。`lib/vendor/` サブディレクトリをオートロードしたい場合、新しいエントリをアプリケーションの `autoload.yml` 設定ファイルに追加します: 
    6969 
    7070    [yml] 
    …… 
    7979  * オートロードメカニズムをすでに持つ `lib/vendor/` ディレクトリの下でライブラリを設置する場合、symfony はファイルを再解析してキャッシュに不要なたくさんの情報を追加します (#5893 - http://trac.symfony-project.org/ticket/5893 を参照)。 
    8080 
    81   * symfony のディレクトリが `lib/vendor/symfony/` という名前でなければ、プロジェクトのオートローダーは symfony ディレクトリ全体を再解析し何らかの問題が起こります (#6064 - http://trac.symfony-project.org/ticket/6064 を参照)。 
     81  * symfony のディレクトリが `lib/vendor/symfony/` という名前でなければ、プロジェクトのオートローダーは symfony ディレクトリ全体を再解析するために何らかの問題が起こります (#6064 - http://trac.symfony-project.org/ticket/6064 を参照)。 
    8282 
    8383symfony 1.3 のオートロード機能は大文字と小文字を区別しません。 
    …… 
    9090`lazy_routes_deserialize` オプションはもはや必要ないので削除されました。 
    9191 
    92 symfony 1.3 に関しては、ルーティングキャッシュが無効にされました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなかった場合、これはすべてのアプリケーションで自動的に無効になります。1.3にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立つのか確認するためにルーティングキャッシュを追加するとよいでしょう。`factories.yml` に追加することで symfony 1.2 のデフォルトに戻すコンフィギュレーションは次のとおりです: 
     92symfony 1.3 に関しては、ルーティングキャッシュが無効にされました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3 にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。`factories.yml` に追加することで symfony 1.2 のデフォルトに戻すコンフィギュレーションは次の通りです: 
    9393 
    9494    [yml] 
    …… 
    120120 * フィルターが簡単に無効にできるとしても、最初に存在を知らなければならず"背後"のマジックがはたらいているのでこれは簡単なタスクではありません。 
    121121 
    122  * ヘルパーを使えばいつどこでアセットがレイアウトにインクルードされるのかよりもよりきめ細かくコントロールできます (たとえば `head` タグのスタイルシート、`body` タグが終わる直前の JavaScript) 
    123  
    124  * 暗黙よりも明示的であるほうが常に優れています (おまじないがなくなんじゃこりゃと驚かずに済みます; この問題に対する苦情はメーリングリストを参照)。 
    125  
    126  * これは小さな速度の改善を提供します。 
     122 * ヘルパーを使えばいつどこでアセットがレイアウトにインクルードされるのかよりきめ細かくコントロールできます (たとえば `head` タグのスタイルシート、`body` タグが終わる直前の JavaScript) 
     123 
     124 * つねに暗黙よりも明示的であるほうが優れています (おまじないがないのでなんじゃこりゃと驚かずに済みます; この問題に対する苦情はメーリングリストを参照してください)。 
     125 
     126 * これは速度の小さな改善を提供します。 
    127127 
    128128アップグレードするには？ 
    129129 
    130   * `common` フィルターをすべての `filters.yml` から削除する必要がある設定ファイル (これは `project:upgrade1.3` タスクによって自動的に行われる)。 
    131  
    132   * 以前と同じふるまいにするには `include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (これはアプリケーションの `templates/` ディレクトリに収められている HTMLレイアウト用の `project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグをもたなければなりません; ほかのレイアウト、もしくはレイアウトを持たないが JavaScript ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。 
     130  * `common` フィルターをすべての `filters.yml` から削除する必要がある設定ファイル (これは `project:upgrade1.3` タスクによって自動的に行われます)。 
     131 
     132  * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (これはアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の `project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグを持たなければなりません; ほかのレイアウト、もしくはレイアウトを持たないが JavaScript ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。 
    133133 
    134134 
    …… 
    140140------ 
    141141 
    142 次のタスククラスはリネームされました: 
     142次のタスククラスは改名されました: 
    143143 
    144144  symfony 1.2               | symfony 1.3 
    …… 
    152152### フォーマッター 
    153153 
    154 `sfFormatter::format()` の3番目の引数は削除されました。 
     154`sfFormatter::format()` の 3 番目の引数は削除されました。 
    155155 
    156156エスケーピング 
    157157------------- 
    158158 
    159 `ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が`37`から`177`である文字のみがエスケープされませんでした。現在はバックスラッシュ: `\`、クォート: `'` & `"` と改行: `\n` & `\r`のみをエスケープします。 
    160  
    161 Doctrine 統合 
    162 ------------- 
     159`ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が`37`から`177`である文字のみがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) のみをエスケープします。 
     160 
     161Doctrine との統合 
     162----------------- 
    163163 
    164164### Doctrine の必須バージョン 
    …… 
    166166Doctrine の svn:externals は最新の Doctrine 1.2 を使うように更新されました。Doctrine 1.2 の新しい機能に関しては[ここ](http://www.doctrine-project.org/upgrade/1_2)をご覧ください。 
    167167 
    168 ### admin ジェネレーターの削除機能 
    169  
    170 admin ジェネレーターバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに `delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。 
     168### アドミンジェネレーターの削除機能 
     169 
     170アドミンジェネレーターバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに `delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。 
    171171 
    172172### Doctrine プラグインスキーマをオーバーライドする 
    …… 
    184184### クエリのロギング 
    185185 
    186 Doctrine 統合ログクエリはロガーオブジェクトに直接アクセスする代わりに `sfEventDispatcher` を使うことで機能します。加えて、これらのイベントの対象はコネクションもしくはクエリを実行するステートメントです。ロギングは新しい `sfDoctrineConnectionProfiler` クラスによって行われ、このクラスは `sfDoctrineDatabase` オブジェクトをとおしてアクセスできます。 
     186Doctrine 統合ログクエリはロガーオブジェクトに直接アクセスする代わりに `sfEventDispatcher` を使うことで機能します。加えて、これらのイベントの対象は接続もしくはクエリを実行するステートメントです。ロギングは新しい `sfDoctrineConnectionProfiler` クラスによって行われ、このクラスは `sfDoctrineDatabase` オブジェクトを通してアクセスできます。 
    187187 
    188188プラグイン 
    189189---------- 
    190190 
    191 `ProjectConfiguration` クラスで有効にされるプラグインを管理するために `enableAllPluginsExcept()` メソッドを使う場合、異なるプラットフォームのあいだの一貫性を保証するために名前でプラグインをソートするように警告されます。 
     191`ProjectConfiguration` クラスで有効にされるプラグインを管理するために `enableAllPluginsExcept()` メソッドを使う場合、異なるプラットフォームのあいだの一貫性を保証するためにプラグインを名前順でソートするように警告されます。 
    192192 
    193193ウィジェット 
    …… 
    199199-------- 
    200200 
    201 symfony 1.3 は新しいメーラーファクトリーを持ちます。アプリケーションを作るとき、`factories.yml` は `test` と `dev` 環境の実用的なデフォルトを持ちます。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために`factories.yml` を次のコンフィギュレーションにアップデートするとよいでしょう: 
     201symfony 1.3 は新しいメーラーファクトリを持ちます。アプリケーションを作るとき、`factories.yml` は `test` と `dev` 環境の実用的なデフォルトを持ちます。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために`factories.yml` を次のコンフィギュレーションにアップデートするとよいでしょう: 
    202202 
    203203    [yml] 
    …… 
    206206        delivery_strategy: none 
    207207 
    208 以前のコンフィギュレーションによって、メールは送信されません。もちろん、これらはまだロギングされ、`mailer` テスターは機能テストでまだ動きます。 
    209  
    210 ひとつのアドレスですべてのメールを受け取りたいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境): 
     208以前のコンフィギュレーションでは、メールは送信されません。もちろん、これらはまだロギングされ、`mailer` テスターは機能テストでまだ動きます。 
     209 
     2101 つのアドレスですべてのメールを受信したいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境): 
    211211 
    212212    [yml] 
    …… 
    220220---- 
    221221 
    222 sfYAML は1.2の仕様とより互換性を持ちます。設定ファイルで変更する必要のあるものは次のとおりです: 
     222sfYAML は 1.2 の仕様とより互換性を持ちます。設定ファイルで変更する必要のあるものは次の通りです: 
    223223 
    224224 * ブール値は文字列の `true` もしくは `false` でのみ表現されます。次のリストのなかの代替文字列を使っている場合、これらを `true` もしくは `false` に置き換えなければなりません: 
    …… 
    237237------ 
    238238 
    239 symfony の以前のバージョンで使われていたカスタムの Propel ビルダークラスは新しい Propel 1.4 のビヘイビアクラスに置き換えられました。この強化を利用するにはプロジェクトの `propel.ini` ファイルをアップデートしなければなりません。 
     239symfony の以前のバージョンで使われていた Propel のカスタムビルダークラスは新しい Propel 1.4 のビヘイビアクラスに置き換わりました。この強化を利用するにはプロジェクトの `propel.ini` ファイルをアップデートしなければなりません。 
    240240 
    241241古いビルダークラスを削除します: 
    …… 
    259259    propel.behavior.symfony_timestampable.class    = plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorTimestampable 
    260260 
    261 `project:upgrade` タスクはこの変更を行おうとしますが、`propel.ini` にローカルな変更をする場合、不可能です。 
     261`project:upgrade` タスクはこの変更を行おうとしますが、`propel.ini` でローカルな変更を行う場合、不可能です。 
    262262 
    263263symfony 1.2 では `BaseFormFilterPropel` クラスは `lib/filter/base` に正しく生成されませんでしたが、symfony 1.3 で訂正されました; クラスは `lib/filter` に生成されます。`project:upgrade` タスクはこのファイルを移動させます。 
    …… 
    276276    $autoload->register(); 
    277277 
    278 `project:upgrade` タスクはこの変更を行おうとしますが、`test/bootstrap/unit.php` へのローカルな変更をする場合は不可能であることがあります。 
     278`project:upgrade` タスクはこの変更を行おうとしますが、`test/bootstrap/unit.php` でローカルな変更をする場合は不可能であることがあります。 

  • doc/branches/1.4/tutorial/ja/whats-new.markdown

    r26772 r27631  
    22============================= 
    33 
    4 このチュートリアルでは symfony 1.3/1.4 のための技術的な内容をおおまかに紹介します。このチュートリアルは symfony 1.2 ですでに作業をしており、symfony 1.3/1.4 の新しい機能を速く学びたい開発者向けです。 
     4このチュートリアルでは symfony 1.3/1.4 のための技術的な内容をおおまかに紹介します。このチュートリアルはすでに symfony 1.2 で作業をしており、symfony 1.3/1.4 の新しい機能を早く学びたい開発者を対象としています。 
    55 
    66最初に、symfony 1.3/1.4 は PHP 5.2.4 とそれ以降と互換性があることにご注意ください。 
    77 
    8 1.2からアップグレードしたいのであれば、symfony の配布ファイルの中で見つかる["プロジェクトを1.2から1.3/1.4にアップグレードする"](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)ファイルをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。 
     81.2からアップグレードしたいのであれば、[「プロジェクトを 1.2 から 1.3/1.4 にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。 
    99 
    1010 
    …… 
    1212-------- 
    1313 
    14 symfony 1.3/1.4 では SwiftMailer 4.1 に基づく新しい標準メーラーが用意されました。 
     14symfony 1.3/1.4 では SwiftMailer 4.1 にもとづく新しい標準メーラーが用意されました。 
    1515 
    1616メールの送信はシンプルでアクションから `composeAndSend()` メソッドを使うだけです: 
    …… 
    1919    $this->getMailer()->composeAndSend('from@example.com', 'to@example.com', 'Subject', 'Body'); 
    2020 
    21 より柔軟性をもたせる必要があれば、`compose()` メソッドを使い後で送信することもできます。添付ファイルをメッセージに追加する方法は次のとおりです: 
     21より柔軟性をもたせる必要があれば、後で `compose()` メソッドを使って送信することもできます。添付ファイルをメッセージに追加する方法は次の通りです: 
    2222 
    2323    [php] 
    …… 
    2828    $this->getMailer()->send($message); 
    2929 
    30 メーラーはとても強力なので、詳細な情報は公式マニュアルを参照してください。 
     30メーラーはとても強力なので、詳しい情報は公式マニュアルを参照してください。 
    3131 
    3232セキュリティ 
    …… 
    6262  * `sfWidgetFormI18nChoiceTimezone` 
    6363 
    64 これらの最初の3つは廃止予定の `sfWidgetFormI18nSelectLanguage`、`sfWidgetFormI18nSelectCurrency` と `sfWidgetFormI18nSelectCountry` ウィジェットの置き換えです。 
     64これらの最初の 3 つは廃止予定の `sfWidgetFormI18nSelectLanguage`、`sfWidgetFormI18nSelectCurrency` と `sfWidgetFormI18nSelectCountry` ウィジェットの置き換えです。 
    6565 
    6666### 流れるようなインターフェイス 
    …… 
    8787### `sfValidatorUrl` 
    8888 
    89 `sfValidatorUrl` は新しい `protocols` オプションを持つようになりました。次のように特定のプロトコルを許可することができるようになりました: 
     89`sfValidatorUrl` は新しい `protocols` オプションを持つようになりました。次のように特定のプロトコルを許可できるようになりました: 
    9090 
    9191    [php] 
    …… 
    101101### `sfValidatorSchemaCompare` 
    102102 
    103 `sfValidatorSchemaCompare` クラスは２つの新しいコンパレーターを持つようになりました: 
    104  
    105  * `IDENTICAL`、は`===`と同等; 
    106  * `NOT_IDENTICAL`、は`!==`と同等; 
     103`sfValidatorSchemaCompare` クラスは 2 つの新しいコンパレーターを持つようになりました: 
     104 
     105 * `IDENTICAL` は `===` と同等です; 
     106 * `NOT_IDENTICAL` は `!==` と同等です; 
    107107 
    108108### `sfValidatorChoice`、`sfValidatorPropelChoice`、`sfValidatorDoctrineChoice` 
    109109 
    110 `sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデーターは `multiple` オプションが `true` の場合のみ有効になるふたつの新しいオプションを持ちます: 
    111  
    112  * `min` 選択される必要がある最小の数 
    113  * `max` 選択される必要がある最大の数 
     110`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデーターは `multiple` オプションが `true` の場合のみ有効になる 2 つのの新しいオプションを持ちます: 
     111 
     112 * `min` 選択する必要がある最小の数 
     113 * `max` 選択する必要がある最大の数 
    114114 
    115115### 国際化バリデーター 
    …… 
    126126    sfValidatorBase::setDefaultMessage('required', 'This field is required.'); 
    127127 
    128 上記のコードはすべてのバリデーターのためにデフォルトの'Required.'メッセージをオーバーライドします。標準のメッセージはどのバリデーターが作成される前に定義しておかなければならないことに注意してください (コンフィグレーションクラスがよい場所です)。 
     128上記のコードはすべてのバリデーターのデフォルトメッセージである 'Required.' をオーバーライドします。標準メッセージはどのバリデーターが作成される前に定義しておかなければならないことに注意してください (コンフィグレーションクラスがよい場所です)。 
    129129 
    130130>**NOTE** 
    …… 
    133133symfony がエラーを表示するとき、使われるエラーメッセージは次のように決定されます: 
    134134 
    135   * symfony はバリデーターが作成されたときに渡されたメッセージを探します (バリデーターのコンストラクターの第２引数経由); 
     135  * symfony はバリデーターが作られるときに渡されたメッセージを探します (バリデーターのコンストラクターの第 2 引数経由); 
    136136 
    137137  * 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージを探します; 
    …… 
    169169    } 
    170170 
    171 デフォルトでは、フィールドの配列はフィールドの順序を変更するためにも使われます。自動的な順序づけを無効にするには、`useFields()` に2番目の引数として `false` を 渡します。 
     171デフォルトでは、フィールドの配列はフィールドの順序を変更するのにも使われます。自動的な順序づけを無効にするには、`useFields()` に 2 番目の引数として `false` を 渡します。 
    172172 
    173173### `sfForm::getEmbeddedForm($name)` 
    …… 
    198198### `BaseForm` 
    199199 
    200 symfony 1.3/1.4 のすべての新しいプロジェクトには Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使うことができる `BaseForm` クラスが入ります。 `sfDoctrinePlugin` と `sfPropelPlugin` によって生成されるフォームは自動的にこのクラスを継承します。追加のフォームクラスを作るのであれば `sfForm` よりも `BaseForm` を継承すべきです。 
     200symfony 1.3/1.4 のすべての新しいプロジェクトには Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使うことができる `BaseForm` クラスが入りました。`sfDoctrinePlugin` と `sfPropelPlugin` によって生成されるフォームは自動的にこのクラスを継承します。追加のフォームクラスを作るのであれば `sfForm` よりも `BaseForm` を継承すべきです。 
    201201 
    202202### `sfForm::doBind()` 
    …… 
    206206### `sfForm(Doctrine|Propel)::doUpdateObject()` 
    207207 
    208 Doctrine と Propel のフォームクラスに開発者が扱いやすい `->doUpdateObject()` メソッドが加えられました。このメソッドは すでに `->processValues()` によって処理された `->updateObject()` から値の配列を受けとります。 
     208Doctrine と Propel のフォームクラスに開発者が扱いやすい `->doUpdateObject()` メソッドが加えられました。このメソッドは すでに `->processValues()` によって処理された `->updateObject()` から値の配列を受け取ります。 
    209209 
    210210### `sfForm::enableLocalCSRFProtection()` と `sfForm::disableLocalCSRFProtection()` 
    211211 
    212 `sfForm::enableLocalCSRFProtection()` と `sfForm::disableLocalCSRFProtection()` メソッドを使うとき、あなたのクラスの `configure()` メソッドから簡単に CSRF 防止機能を設定することができます。 
     212`sfForm::enableLocalCSRFProtection()` と `sfForm::disableLocalCSRFProtection()` メソッドを使うとき、あなたのクラスの `configure()` メソッドから簡単に CSRF 防止機能を設定できます。 
    213213 
    214214CSRF 防止機能を無効にするには、次のような行を `configure()` メソッドに追加します: 
    …… 
    217217    $this->disableLocalCSRFProtection(); 
    218218 
    219 `disableLocalCSRFProtection()` を呼び出すことによって、フォームインスタンスを作成するときに CSRF 対策の秘密の文字列を渡したとしても CSRF 防止機能は無効になります。 
     219`disableLocalCSRFProtection()` を呼び出すことによって、フォームインスタンスを作るときに CSRF 対策の秘密の文字列を渡したとしても CSRF 防止機能は無効になります。 
    220220 
    221221### 流れるようなインターフェイス 
    …… 
    237237### テストのスピードアップ 
    238238 
    239 大規模なテストスイートの場合、変更するたびに全てのテストを起動するのにとても時間をかかる可能性があります。特にテストが通らない場合などはそうでしょう。なぜならテストを修正するたびに、何も壊していないことを確認するためにテストスイート全体を再度実行することになるからです。しかし、テストが修正されない限り、全てのテストを再実行する必要はありません。symfony 1.3/1.4 では `test:all` と `symfony:test` タスクは前回の実行時に通らなかったテストだけを再実行する `--only-failed` (`-f` がショートカットになります) オプションを持つようになりました: 
     239大規模なテストスイートの場合、変更するたびにすべてのテストを起動するのにとても時間をかかる可能性があります。特にテストが通らない場合などはそうでしょう。なぜならテストを修正するたびに、何も壊していないことを確認するためにテストスイート全体を再度実行することになるからです。しかし、テストが修正されないかぎり、すべてのテストを再実行する必要はありません。symfony 1.3/1.4 では `test:all` と `symfony:test` タスクは前回の実行時に通らなかったテストだけを再実行する `--only-failed` (`-f` がショートカットになります) オプションを持つようになりました: 
    240240 
    241241    $ php symfony test:all --only-failed 
    242242 
    243 どのように動作するかを説明します: まず最初に、全てのテストはいつもどおりに実行されます。しかし引き続きテストを実行しても、最後のテストで通らなかったものだけが実行されます。コードを修正したら、テストは通り次回以降の実行からは除外されます。再び全てのテストが通ったら、あなたは完全なテストスイートを実行し、洗い流し繰り返すことができます。 
     243どのように動作するのかを説明します: まず最初に、すべてのテストはいつも通りに実行されます。しかし引き続きテストを実行しても、最後のテストで通らなかったものだけが実行されます。コードを修正したら、テストが通り次回以降の実行から除外されます。再びすべてのテストが通ったら、あなたは完全なテストスイートを実行し、洗い流し繰り返すことができます。 
    244244 
    245245### 機能テスト 
    …… 
    247247リクエストが例外を生成するとき、レスポンステスターの `debug()` メソッドは HTML 標準出力の代わりに、人間が読める例外のテキストの説明を出力するようになりました。より簡単にデバッグできるようになります。 
    248248 
    249 `sfTesterResponse` はレスポンスの内容全体に対して正規表現で検索を行える新しい `matches()` メソッドを持つようになりました。XML のようなレスポンスではないもの、それは `checkElement()` が使えないようなレスポンスですが、そういった場合にとても役立ちます。ひ弱だった `contains()` メソッドの代わりにも使うことができます: 
     249`sfTesterResponse` はレスポンスの内容全体に対して正規表現で検索を行える新しい `matches()` メソッドを持つようになりました。XML のようなレスポンスではないもの、それは `checkElement()` が使えないようなレスポンスですが、そういった場合にとても役立ちます。ひ弱だった `contains()` メソッドの代わりとして使うこともできます: 
    250250 
    251251    [php] 
    …… 
    258258### JUnit と互換性のある XML 出力 
    259259 
    260 テストタスクは `--xml` オプションを使うことで JUnit と互換性のある XML ファイルも出力できるようになりました: 
     260`--xml` オプションを使うことでテストタスクは JUnit と互換性のある XML ファイルも出力できるようになりました: 
    261261 
    262262    $ php symfony test:all --xml=log.xml 
    …… 
    270270### lime による出力の色づけ 
    271271 
    272 symfony 1.3/1.4 では、lime は色づけを正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクターの第２引数を省略できるということです: 
     272symfony 1.3/1.4 では、lime は色づけを正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクターの第 2 引数を省略できるということです: 
    273273 
    274274    [php] 
    …… 
    277277### `sfTesterResponse::checkForm()` 
    278278 
    279 フォームの全てのフィールドが正しくレンダリング処理されてレスポンスに含まれているかどうかをより簡単に確かめられるメソッドがレスポンステスターに収録されました: 
     279フォームのすべてのフィールドが正しくレンダリング処理されてレスポンスに含まれているかどうかをより簡単に確かめられるメソッドがレスポンステスターに入りました: 
    280280 
    281281    [php] 
    …… 
    292292    end(); 
    293293 
    294 レスポンスが複数のフォームを含む場合は、どの DOM 部分をテストするかをピンポイントで指定する CSS セレクターを提供するオプションがあります: 
     294レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをピンポイントで指定する CSS セレクターを提供するオプションがあります: 
    295295 
    296296    [php] 
    …… 
    324324### `context.load_factories` をリスニングする 
    325325 
    326 `context.load_factories` イベントのリスナーを機能テストに追加できるようになりました。これは symfony の以前のバージョンではできませんでした。 
     326`context.load_factories` イベントのリスナーを機能テストに追加できるようになりました。これは symfony の以前のバージョンでは利用できませんでした。 
    327327 
    328328 
    …… 
    330330    $browser->addListener('context.load_factories', array($browser, 'listenForNewContext')); 
    331331 
    332 ### よりよい `->click()` 
    333  
    334 CSS セレクターを`->click()` メソッドに 渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になります。 
     332### 改良された `->click()` 
     333 
     334`->click()` メソッドに CSS セレクターを渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になりました。 
    335335 
    336336    [php] 
    …… 
    343343------ 
    344344 
    345 symfony の CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI は幅をデフォルトの78カラムに合わせようとします。 
     345symfony の CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI は幅をデフォルトの 78 カラムに合わせようとします。 
    346346 
    347347### `sfTask::askAndValidate()` 
    348348 
    349 ユーザーに質問をして得られた入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新しくできました: 
     349ユーザーに質問をして得られた入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新しく用意されました: 
    350350 
    351351    [php] 
    …… 
    356356### `symfony:test` 
    357357 
    358 ときどき、開発者は特定のプラットフォームで symfony が正しく動作するのかをチェックするために symfony のテストスイートを実行する必要があります。従来は、symfony に附属している `prove.php` スクリプトを実行し確認しなければなりませんでした。symfony 1.3/1.4 では組み込みのタスク、コマンドラインから symfony のコアテストスイートを起動できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます: 
     358ときには、開発者は特定のプラットフォームで symfony が正しく動作するのかをチェックするために symfony のテストスイートを実行する必要があります。従来は、symfony に附属している `prove.php` スクリプトを実行し確認しなければなりませんでした。symfony 1.3/1.4 では組み込みのタスク、コマンドラインから symfony のコアテストスイートを起動できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます: 
    359359 
    360360    $ php symfony symfony:test 
    …… 
    365365### `project:deploy` 
    366366 
    367 `project:deply` タスクはちょっと改良されました。リアルタイムでファイルの転送状況を表示するようになりました。ただし、`-t` オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません、もちろんエラーは除きます。エラー時には、エラーの情報を出力し簡単に問題を認識できるように赤色の背景に出力します。 
     367`project:deply` タスクは少し改良されました。リアルタイムでファイルの転送状況を表示するようになりました。ただし、`-t` オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません、もちろんエラーは除きます。エラー時には、エラーの情報を出力し簡単に問題を認識できるように赤色の背景に出力します。 
    368368 
    369369### `generate:project` 
    …… 
    386386より詳しい情報は公式ブログの[記事](http://www.symfony-project.org/blog/2009/06/10/new-in-symfony-1-3-project-creation-customization)にあります。 
    387387 
    388 プロジェクトを生成するとき、2番目の引数として著者の名前を渡すことができます。これは symfony が新しいクラスを生成するときに phpdoc の `@author` タグに使う値を指定します。 
     388プロジェクトを生成するとき、2番目の引数として著者の名前を渡すことができます。これは symfony が新しいクラスを生成するときに PHPDoc の `@author` タグに使う値を指定します。 
    389389 
    390390    $ php /path/to/symfony generate:project foo "Joe Schmo" 
    …… 
    392392### `sfFileSystem::execute()` 
    393393 
    394 `sfFileSystem::execute()` メソッドは `sfFileSystem::sh()` メソッドをより強力な機能で置き換えます。このメソッドは `stdout` と `stderr` 出力のリアルタイム処理のコールバックをとります。また両方の出力を配列として返すこともできます。`sfProjectDeployTask` クラスで使い方の例を見つけることができます。 
     394`sfFileSystem::execute()` メソッドは `sfFileSystem::sh()` メソッドをより強力な機能に置き換えます。このメソッドは `stdout` と `stderr` 出力のリアルタイム処理のコールバックをとります。また両方の出力を配列として返すこともできます。`sfProjectDeployTask` クラスで使い方の例を見つけることができます。 
    395395 
    396396### `task.test.filter_test_files` 
    …… 
    420420### `sfBaseTask::setConfiguration()` 
    421421 
    422 PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run()` に `--application` と `--env` オプションを渡す必要はもうありません。その代わりに、ただ `->setConfiguration()` を呼び出すだけで設定オブジェクトを直接セットすることができます。 
     422PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run()` に `--application` と `--env` オプションを渡す必要はもはやありません。その代わりに、ただ `->setConfiguration()` を呼び出すだけで設定オブジェクトを直接セットすることができます。 
    423423 
    424424    [php] 
    …… 
    462462この出力は新しい `sfTask::asXml()` メソッドにもとづいており、これはタスクオブジェクトの XML 表現を返します。 
    463463 
    464 たいていの場合において XML 出力は IDE のようなサードパーティーにとても役立つでしょう。 
     464たいていの場合において XML 出力は IDE のようなサードパーティにとても役立つでしょう。 
    465465 
    466466### `project:optimize` 
    …… 
    493493可能であれば、開発環境の例外ページで Web デバッグツールバーが表示されます。 
    494494 
    495 Propel 統合 
    496 ----------- 
     495Propel との統合 
     496--------------- 
    497497 
    498498Propel はバージョン1.4にアップグレードされました。Propel のアップグレードに関する詳しい情報は[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。 
    …… 
    504504### `propel:insert-sql` 
    505505 
    506 `propel:insert-sql` がデータベースから全てのデータを削除する前に確認を行います。このタスクは複数のデータベースからデータを削除することができるので、関連するデータベースの接続名も表示するようになりました。 
     506`propel:insert-sql` がデータベースからすべてのデータを削除する前に確認を行います。このタスクは複数のデータベースからデータを削除することができるので、関連するデータベースの接続名も表示するようになりました。 
    507507 
    508508### `propel:generate-module`、`propel:generate-admin`、`propel:generate-admin-for-route` 
    …… 
    521521          timestampable: ~ 
    522522 
    523 もしくは、古い `schema.yml` 構文を使う場合: 
     523もしくは、古い `schema.yml` 構文を使う場合次のようになります: 
    524524 
    525525    propel: 
    …… 
    560560### デフォルトの要件 
    561561 
    562 `column` オプションがデフォルトの `id` になっているとき、デフォルトの必須要件の `\d+` は `sfObjectRouteCollection` にだけ適用されるようになりました。(`slug` のような) 数字でないカラムが指定されているとき代わりの必須要件を用意する必要はないということです。 
     562`column` オプションがデフォルトの `id` であるとき、デフォルトの必須要件の `\d+` は `sfObjectRouteCollection` にだけ適用されるようになりました。このことが意味するのは (`slug` のような) 数字でないカラムが指定されているとき代わりの必須要件を用意する必要はないということです。 
    563563 
    564564### `sfObjectRouteCollection` オプション 
    …… 
    578578### 出力の色づけ 
    579579 
    580 symfony の CLI を使うとき、symfony はあなたが利用しているコンソールが色つき出力をサポートしているかどうかを推測しようとします。しかし、symfony は推測を間違える場合があります; たとえば、Cygwin を使っているときです (Windows プラットフォームではカラー出力は常に切られているからです)。 
    581  
    582 symfony 1.3/1.4 では、グローバルオプションの `--color` を渡すことで色つき出力することを強制できるようになりました。 
    583  
    584 国際化(I18N) 
    585 ---- 
     580symfony の CLI を使うとき、symfony はあなたが利用しているコンソールが色つき出力をサポートしているかどうかを推測しようとします。しかし、symfony は推測を間違える場合があります; たとえば、Cygwin を使っているときです (Windows プラットフォームでは色つき出力はつねにオフだからです)。 
     581 
     582symfony 1.3/1.4 では、グローバルオプションの `--color` を渡すことで色つき出力を強制できるようになりました。 
     583 
     584国際化 (I18N) 
     585------------- 
    586586 
    587587### データの更新 
    588588 
    589 すべての国際化オペレーションに使われるデータは `ICU` プロジェクトから更新されました。symfony には約330のロケールファイルが付属しており、symfony 1.2 と比べると約70増えています。ですのでたとえば、言語リストの10番目の項目をチェックするテストケースが通らない可能性があることにご注意をお願いします。 
     589すべての国際化オペレーションに使われるデータは `ICU` プロジェクトから更新されました。symfony には約 330 個のロケールファイルが付属しており、symfony 1.2 と比べると約 70 個増えています。ですのでたとえば、言語リストの 10 番目の項目をチェックするテストケースが通らない可能性があることにご注意をお願いします。 
    590590 
    591591### ユーザーロケールを基準にソートする 
    592592 
    593 このロケールに依存するデータでのすべてのソートもロケールに依存して実行されます。この目的のために `sfCultureInfo->sortArray()` を使うことができます。 
     593このロケールに依存するデータにおけるすべてのソートもロケールに依存して実行されます。この目的のために `sfCultureInfo->sortArray()` を使うことができます。 
    594594 
    595595プラグイン 
    596596---------- 
    597597 
    598 symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin` 以外のすべてのプラグインはデフォルトで有効にされました: 
     598symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin` 以外のすべてのプラグインはデフォルトで有効にされていました: 
    599599 
    600600    [php] 
    …… 
    608608    } 
    609609 
    610 symfony 1.3/1.4 では、新しく作られたプロジェクトでプラグインを使うためには `ProjectConfiguration` クラスで明示的に有効にしなければなりません: 
     610symfony 1.3/1.4 では、新しく作られたプロジェクトでプラグインを使うには `ProjectConfiguration` クラスで明示的に有効にしなければなりません: 
    611611 
    612612    [php] 
    …… 
    644644### `sf_file_link_format` 
    645645 
    646 symfony 1.3/1.4 は可能であるときにファイルパスをクリック可能なリンクにフォーマットします (すなわちデバッグ例外のテンプレート)。`sf_file_link_format` がセットされる場合、この目的に使われ、そうでなければ、symfony は PHP コンフィギュレーションの `xdebug.file_link_format` の値を探します。 
     646symfony 1.3/1.4 は可能であるときにファイルパスをクリック可能なリンク (すなわちデバッグ例外のテンプレート) にフォーマットします。`sf_file_link_format` がセットされている場合、この目的に使われ、そうでなければ、symfony は PHP コンフィギュレーションの `xdebug.file_link_format` の値を探します。 
    647647 
    648648たとえば、TextMate でファイルを開きたい場合、次のコードを `settings.yml` に追加します: 
    …… 
    658658----------------- 
    659659 
     660Doctrine は1.2にアップグレードされました。アップグレードに関する詳しい情報は [Doctrine の公式サイト](http://www.doctrine-project.org/documentation/1_2/ja)を訪問してくださるようお願いします。 
     661 
    660662### フォームクラスを生成する 
    661663 
    662 Doctrine は1.2にアップグレードされました。アップグレードに関する詳しい情報は [Doctrine のサイト](http://www.doctrine-project.org/documentation/1_2/ja)を訪問してくださるようお願いします。 
    663  
    664 ### フォームクラスを生成する 
    665  
    666 symfony の追加オプションを Doctrine の YAML スキーマファイルで指定することが可能になりました。そしてフォームとフィルタークラスの生成を無効にするいくつかのオプションも追加しました。 
     664symfony の追加オプションを Doctrine の YAML スキーマファイルで指定できるようになりました。そしてフォームとフィルタークラスの生成を無効にするオプションもいくつか追加されました。 
    667665 
    668666たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルターフォームクラスを生成させる必要はありません。ですので次のようなことができます: 
    …… 
    683681### フォームクラスの継承 
    684682 
    685 あなたのモデルクラスからフォームを生成するとき、モデルクラスは継承を含んでいます。生成された子クラスは継承を尊重し、同じ継承構造に続くフォームを生成します。 
     683モデルクラスからフォームを生成するとき、モデルクラスは継承を含んでいます。生成された子クラスは継承を尊重し、同じ継承構造に続くフォームを生成します。 
    686684 
    687685### 新しいタスク 
    …… 
    705703#### モデルファイルをクリーンにする 
    706704 
    707 `doctrine:clean-model-files` タスクで上記プロセスを自動化しどのモデルがディスクに存在するが YAML スキーマファイルに存在しないかを見つけることができます。 
     705上記のプロセスを`doctrine:clean-model-files` タスクで自動化することで、どのモデルがディスクに存在するが YAML スキーマファイルに存在しないかを見つけることができます。 
    708706 
    709707    $ php symfony doctrine:clean-model-files 
    710708 
    711 上記コマンドは YAML スキーマファイルと生成されたモデルやファイルと比較し、どれを削除すべきかを決定します。これらのモデルは `doctrine:delete-model-files` タスクに伝えられます。タスクは自動的に削除する前にどのファイルが削除されるのか確認を求めます。 
     709上記コマンドは YAML スキーマファイルと生成モデルやファイルと比較し、どれを削除すべきかを決定します。これらのモデルは `doctrine:delete-model-files` タスクに伝えられます。タスクは自動的に削除する前にどのファイルが削除されるのか確認を求めます。 
    712710 
    713711#### データをリロードする 
    …… 
    730728新しい `doctrine:build` タスクによって明確に symfony や Doctrine にビルドしてほしいものを何でも指定できます。このより柔軟性のある解決方法に合わせて廃止予定になった既存の多くのタスクを組み合わせることで得られる機能をこのタスクを複製します。 
    731729 
    732 `doctrine:build` の使い方は次のとおりです: 
     730`doctrine:build` の使い方は次の通りです: 
    733731 
    734732    $ php symfony doctrine:build --db --and-load 
    …… 
    764762    $ php symfony doctrine:generate-migration AddUserEmailColumn --editor-cmd=mate 
    765763 
    766 この例はマイグレーションクラスを生成し TextMate で新しいファイルを開いています。 
     764この例ではマイグレーションクラスを生成し TextMate で新しいファイルを開きます。 
    767765 
    768766#### `doctrine:generate-migrations-diff` 
    …… 
    784782      ->format('m/d/Y'); 
    785783 
    786 日付の値も `setDateTimeObject` メソッドを呼び出し有効な `DateTime` インスタンスを渡すだけでセットすることもできます。 
     784`setDateTimeObject` メソッドを呼び出し有効な `DateTime` インスタンスを渡すだけで日付の値もセットできます。 
    787785 
    788786    [php] 
    …… 
    801799    $ php symfony doctrine:migrate --dry-run 
    802800 
    803 ### DQL タスクをテーブルのデータとして出力する 
    804  
    805 これまでは `doctrine:sql` コマンドを実行するとただ YAML 書式で出力されるだけでした。新しい `--table` オプションが追加されました。このオプションによってデータをテーブル表示で出力することができるようなり、MySQL のコマンドラインの出力に似たものになっています。 
     801### DQL タスクをテーブル形式のデータとして出力する 
     802 
     803これまでは `doctrine:sql` コマンドを実行するとただ YAML 形式で出力されるだけでした。新しい `--table` オプションが追加されました。このオプションによってデータをテーブル表示で出力することができるようなり、MySQL のコマンドラインの出力に似たものになっています。 
    806804 
    807805それで、次のようなことが可能になりました。 
    …… 
    818816    (2 results) 
    819817 
    820 ### クエリパラメータを `doctrine:dql` に渡す 
    821  
    822 `doctrine:dql` タスクもクエリパラメータを引数として受け取れるよう強化されました: 
     818### クエリパラメーターを `doctrine:dql` に渡す 
     819 
     820`doctrine:dql` タスクもクエリパラメーターを引数として受け取れるよう強化されました: 
    823821 
    824822    $ php symfony doctrine:dql "FROM Article a WHERE name LIKE ?" John% 
    …… 
    872870    } 
    873871 
    874 フォームフィルターのカスタマイズが簡単になりました。フィールドのフィルタリングを追加するには、必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 
     872フォームフィルターのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するには、必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 
    875873 
    876874    [php] 
    …… 
    896894### Doctrine を設定する 
    897895 
    898 Doctrine を設定するために `doctrine.configure` と `doctrine.configure_connection` イベントをリスニングできます。このことはプラグインが `sfDoctrinePlugin` の前で有効にされている限り、プラグインから Doctrine のコンフィギュレーションを簡単にカスタマイズできることを意味します。 
     896Doctrine を設定するために `doctrine.configure` と `doctrine.configure_connection` イベントをリスニングできます。このことはプラグインが `sfDoctrinePlugin` の前で有効にされているかぎり、プラグインから Doctrine のコンフィギュレーションを簡単にカスタマイズできることを意味します。 
    899897 
    900898### `doctrine:generate-module`、`doctrine:generate-admin`、`doctrine:generate-admin-for-route` 
    …… 
    902900`doctrine:generate-module`、`doctrine:generate-admin`、`doctrine:generate-admin-for-route` タスクは生成モジュールのアクション基底クラスのコンフィギュレーションを可能にする `--actions-base-class` オプションをとります。 
    903901 
    904 ### マジックメソッドの doc タグ 
    905  
    906 symfony が Doctrine モデルに追加するゲッターとセッターのマジックメソッドはそれぞれの生成基底クラスの PHPDoc ヘッダーに現れます。IDE がコード補完をサポートする場合、これらの `getFooBar()` と `setFooBar()` メソッドがモデルオブジェクトに現れることがわかります。`FooBar` はキャメルケースのフィールド名です。 
     902### マジックメソッドの PHPDoc タグ 
     903 
     904symfony が Doctrine モデルに追加するゲッターとセッターのマジックメソッドはそれぞれの生成基底クラスの PHPDoc ヘッダーに現れます。IDE がコード入力補完をサポートする場合、これらの `getFooBar()` と `setFooBar()` メソッドがモデルオブジェクトに現れることがわかります。`FooBar` はキャメルケースのフィールド名です。 
    907905 
    908906### Doctrine の異なるバージョンを使う 
    …… 
    930928`sfWebDebugPanel` パラメーターを URL につけ加えることでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config パネルを開くように Web デバッグツールバーはレンダリングされます。 
    931929 
    932 パネルは Web デバッグの `request_parameters` オプションにアクセスすることでリクエストパラメーターをインスペクトします: 
     930パネルは Web デバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメーターをインスペクトします: 
    933931 
    934932    [php] 
    …… 
    940938### スロットの改善 
    941939 
    942 `get_slot()`と`include_slot()` ヘルパーはスロットが提供されない場合返すデフォルトのスロットの内容を指定するための2番目のパラメーターを受け取ります: 
    943  
    944     [php] 
    945     <?php echo get_slot('foo', 'bar') // もし`foo`スロットが定義されていなければ 'bar'が出力される ?> 
    946     <?php include_slot('foo', 'bar') // もし`foo`スロットが定義されていなければ 'bar'が出力される ?> 
     940`get_slot()` と `include_slot()` ヘルパーはスロットが提供されない場合、返すデフォルトのスロットの内容を指定するための 2 番目のパラメーターを受け取ります: 
     941 
     942    [php] 
     943    <?php echo get_slot('foo', 'bar') // もし `foo` スロットが定義されていなければ  'bar' が出力される ?> 
     944    <?php include_slot('foo', 'bar') // もし `foo` スロットが定義されていなければ  'bar' が出力される ?> 
    947945 
    948946ページャー 
    …… 
    966964ビューキャッシュマネージャーは `factories.yml` でパラメーターを受け取ります。ビューのキャッシュキーの生成はクラスを楽に拡張できるように異なる方法でリファクタリングされてきました。 
    967965 
    968 ふたつのパラメーターが `factories.yml` で利用できます: 
     9662 つのパラメーターが `factories.yml` で利用できます: 
    969967 
    970968  * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメーターで指定されるので、これはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。 
    …… 
    995993### `redirect()` 
    996994 
    997 `sfAction:redirect()` メソッドは symfony 1.2 で導入された `url_for()` の特徴と互換性を持つようになりました。 
     995`sfAction:redirect()` メソッドは symfony 1.2 で導入された `url_for()` の機能と互換性を持つようになりました。 
    998996 
    999997    [php] 
    …… 
    10231021----------- 
    10241022 
    1025 `sfContext` にメソッドを動的に追加するために `context.method_not_found` をリスニングできます。プラグインから遅延ロードファクトリーを追加する場合に便利でしょう。 
     1023`sfContext` にメソッドを動的に追加するために `context.method_not_found` をリスニングできます。プラグインから遅延ロードファクトリを追加する場合に役立つでしょう。 
    10261024 
    10271025    [php] 

  • doc/branches/1.4/tutorial/ja/which-version.markdown

    r25636 r27631  
    1 どちらのバージョンを選べばいいのか？ 
     1どちらのバージョンを選べばよいのか？ 
    22================================== 
    33 
    4 symfony 1.3 と symfony 1.4 のドキュメントはまったく同じものです。ふたつの異なるバージョンでドキュメントがひとつしかない状況はめったにないことなので、このドキュメントではふたつのバージョンの主な違いが何であり、あなたのプロジェクトのために最良の選択をする方法を説明します。 
     4symfony 1.3 と symfony 1.4 のドキュメントはまったく同じものです。2 つの異なるバージョンでドキュメントが 1 つしかない状況はめったにないことなので、このドキュメントでは 2 つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をする方法を説明します。 
    55 
    6 symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年年末) にリリースされ、実際のところ、これらは両方とも**まったく同じ機能一式**を持ちます。ふたつのバージョンの唯一の違いは古い symfony のバージョンとの後方互換性のサポートの状況です 
     6symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009 年の年末) にリリースされ、実際のところ、これらは両方とも**まったく同じ機能一式**を持ちます。2 つのバージョンの唯一の違いは symfony の古いバージョンとの後方互換性のサポート状況です。 
    77 
    8 symfony 1.3 は古い symfony のバージョン (1.0、1.1もしくは1.2) を使うレガシープロジェクトをアップグレードする場合に使いたいリリースです。これは1.3の開発期間に廃止予定の後方互換性レイヤーとすべての機能を持ちます。このことはアップグレードが簡単で、シンプルで、安全でもあることを意味します。 
     8symfony 1.3 は古い symfony のバージョン (1.0、1.1 もしくは 1.2) を使うレガシープロジェクトをアップグレードする場合に使いたいリリースです。これは 1.3 の開発期間に廃止予定の後方互換性レイヤーとすべての機能を持ちます。このことはアップグレードが楽でシンプルであり、そして安全でもあることを意味します。 
    99 
    10 今日新しいプロジェクトを始めるのであれば、symfony 1.4 を使うべきです。このバージョンは symfony 1.3 と同じ機能セットを持ちますが、完全な互換性を含めて、すべての廃止された機能が削除されています。このバージョンは symfony 1.3 よりもクリーンで少し速く動きます。 symfony 1.4 を使う別の大きな利点はより長いサポート期間です。長期間サポートリリースなので、symfony コアチームによって3年間メンテナンスされます (2012年11月まで)。 
     10今日新しいプロジェクトを始めるのであれば、symfony 1.4 を使うべきです。このバージョンは symfony 1.3 と同じ機能セットを持ちますが、完全な互換性を含めて、すべての廃止予定の機能が削除されています。このバージョンは symfony 1.3 よりもクリーンで少し速く動きます。symfony 1.4 を使う別の大きな利点はサポート期間がより長いことです。長期間サポートのリリースなので、symfony コアチームによって 3 年間メンテナンスされます (2012 年 11 月まで)。 
    1111 
    12 もちろん、プロジェクトを symfony 1.3 にマイグレートして symfony 1.3 がサポートされる期間 (2010年11月まで) に廃止予定の機能を削除してコードをゆっくりアップデートしてから長期サポートの恩恵を得るために最終的に symfony 1.4 に移行するための時間が十分にあります。 
     12もちろん、プロジェクトを symfony 1.3 にマイグレートして symfony 1.3 がサポートされる期間 (2010 年 11 月まで) に廃止予定の機能を削除してコードをゆっくりアップデートしてから長期サポートの恩恵を得るために最終的に symfony 1.4 に移行するための時間が十分にあります。 
    1313 
    1414このドキュメントは廃止予定の機能を説明しないので、すべての例は両方のバージョンで等しく動きます。