Development

Changeset 28384

You must first sign up to be able to contribute.

Changeset 28384

Show
Ignore:
Timestamp:
03/04/10 21:19:54 (3 years ago)
Author:
masaki
Message:

[doc-ja][1.4] polished the whole upgrade tutorials

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

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

    r28345 r28384  
    111.3 での廃止予定および削除される機能 
    2 =================================== 
     2==================================== 
    33 
    44このドキュメントでは symfony 1.3 で廃止予定もしくは削除されるすべての設定、クラス、メソッド、関数とタスクの一覧を示します。  
    …… 
    99次のコアプラグインは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 
    1010 
    11   * `sfCompat10Plugin`: このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0 のアドミンジェネレーターとフォームシステム)。これらのなかには `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される 1.0 のアドミンジェネレーターのデフォルトテーマも入っています。 
     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 * `sfToolkit::removeArrayValueForPath()`、 
    2323    `sfToolkit::hasArrayValueForPath()`、と `getArrayValueForPathByRef()` 
    2424 
    25   * `sfValidatorBase::setInvalidMessage()`: 新しい `sfValidatorBase::setDefaultMessage()` メソッドの呼び出しに置き換わります。 
     25  * `sfValidatorBase::setInvalidMessage()`: 新しい `sfValidatorBase::setDefaultMessage()` メソッド呼び出しに置き換わります。 
    2626 
    27   * `sfValidatorBase::setRequiredMessage()`: 新しい `sfValidatorBase::setDefaultMessage()` メソッドの呼び出しに置き換わります。 
     27  * `sfValidatorBase::setRequiredMessage()`: 新しい `sfValidatorBase::setDefaultMessage()` メソッド呼び出しに置き換わります。 
    2828 
    2929  * `sfTesterResponse::contains()`: より強力な `matches()` メソッドを使うことができます 
    …… 
    3131  * `sfTestFunctionalBase` の次のメソッド: `isRedirected()`、`isStatusCode()`、`responseContains()`、 
    3232    `isRequestParameter()`、`isResponseHeader()`、 
    33     `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換わりました。 
     33    `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換わります。 
    3434 
    35   * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換わりました。 
     35  * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは 1.2 以降で廃止予定になり、テスタークラスに置き換わります。 
    3636 
    37   * `sfFilesystem::sh()`: このメソッドのすべての呼び出しを新しい `sfFilesystem::execute()` メソッドの呼び出しに置き換わります。このメソッドの戻り値は `stdout` 出力と `stderr` 出力で構成される配列であることに注意してください。 
     37  * `sfFilesystem::sh()`: このメソッド呼び出しはすべて新しい `sfFilesystem::execute()` メソッド呼び出しに置き換わります。このメソッドの戻り値は `stdout` 出力と `stderr` 出力で構成される配列であることに注意してください。 
    3838 
    3939  * `sfAction::getDefaultView()`、`sfAction::handleError()`、 
    …… 
    4444  * `sfApplicationConfiguration::loadPluginConfig()`: 代わりに `initializePlugins()` を使います。 
    4545 
    46   * `sfLoader::getHelperDirs()` と `sfLoader::loadHelpers()`: `sfApplicationConfiguration` オブジェクトから同じメソッドを使ってください。`sfLoader` クラスのすべてのメソッドは廃止予定になったので、symfony 1.4 で `sfLoader` は削除されます。 
     46  * `sfLoader::getHelperDirs()` と `sfLoader::loadHelpers()`: `sfApplicationConfiguration` オブジェクトから同じメソッドを使ってください。`sfLoader` クラスのすべてのメソッドは廃止予定になったので、`sfLoader` は symfony 1.4 で削除されます。 
    4747 
    4848  * `sfController::sendEmail()`: 代わりに symfony 1.3 の新しいメーラー機能を使います。 
    …… 
    6666次のメソッドと関数は symfony 1.3 で削除されます: 
    6767 
    68   * `sfApplicationConfiguration::checkSymfonyVersion()`: 説明は下記を参照してください (`check_symfony_version` 設定)。 
     68  * `sfApplicationConfiguration::checkSymfonyVersion()`: 説明は下記のセクションを参照してください (`check_symfony_version` 設定)。 
    6969 
    7070クラス 
    …… 
    109109次のヘルパーグループは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 
    110110 
    111   * `sfCompat10Plugin` によって提供される 1.0 フォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` 
     111  * `sfCompat10Plugin` によって提供される 1.0 のフォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` 
    112112 
    113 `form_tag()` ヘルパーは `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4 でも利用可能です。 
     113`form_tag()` ヘルパーの所属は `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4 でも利用可能です。 
    114114 
    115 PHP のインクルードパスからヘルパーをロードする機能は 1.3 で廃止予定になり 1.4 で削除されました。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに設置しなければなりません。 
     115PHP のインクルードパスからヘルパーをロードする機能は 1.3 で廃止予定になり 1.4 で削除されます。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに設置しなければなりません。 
    116116 
    117117設定 
    118118---- 
    119119 
    120 次の設定 (`settings.yml` 設定で管理されます) は symfony 1.3 から削除されました: 
     120次の設定 (`settings.yml` 設定で管理されます) は symfony 1.3 から削除されます: 
    121121 
    122   * `check_symfony_version`: この設定は symfony のバージョンが変更される場合にキャッシュの自動クリーニングを可能にするために数年前に導入されました。これは主にすべての顧客のあいだで同じバージョンの symfony が共有される共用ホスティングのコンフィギュレーションに便利でした。symfony 1.1 以降ではバッドプラクティスですので (プロジェクトごとに symfony のバージョンを組み込む必要があるため)、設定は無意味です。さらに、この設定が `on` にセットされている場合、ファイルのコンテンツを得る必要があるときに、それぞれのリクエストに小さなオーバーヘッドが追加されてしまいます。 
     122  * `check_symfony_version`: この設定は symfony のバージョンが変更される場合にキャッシュの自動クリーニングを可能にするために数年前に導入されました。これはおもにすべての顧客のあいだで同じバージョンの symfony が共有される共用ホスティングのコンフィギュレーションに便利でした。symfony 1.1 以降ではバッドプラクティスですので (プロジェクトごとに symfony のバージョンを組み込む必要があるため)、設定は無意味です。さらに、この設定が `on` にセットされている場合、ファイルのコンテンツを得る必要があるときに、それぞれのリクエストに小さなオーバーヘッドが追加されてしまいます。 
    123123 
    124   * `max_forwards`: この設定は symfony が例外を投げる前に許容される転送の最大回数をコントロールします。これを設定可能にする値はありません。5 回よりも多くの転送が必要な場合、問題の認識とパフォーマンスの両方で問題があります。 
     124  * `max_forwards`: この設定は symfony が例外を投げる前に許容される転送の最大回数をコントロールします。これを設定可能にする値はありません。5回よりも多くの転送が必要な場合、問題の認識とパフォーマンスの両方で問題があります。 
    125125 
    126   * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善のために導入され、この設定はビューキャッシュのために遅延キャッシュキージェネレーションを有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも呼び出される `sfViewCacheManager::isCacheable()` に頼るひともいました。symfony 1.3 に関しては、ふるまいは `sf_lazy_cache_key` が `true` にセットされる場合と同じになります。 
     126  * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善のために導入され、この設定はビューキャッシュのために遅延キャッシュキー生成を有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも呼び出される `sfViewCacheManager::isCacheable()` に頼るひともいました。symfony 1.3 に関して、ふるまいは `sf_lazy_cache_key` が `true` にセットされる場合と同じになります。 
    127127 
    128   * `strip_comments`: `strip_comments` は PHP 5.0.x のトークナイザーのバグが原因のコメントのストリッピング機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかったとき、メモリの大量消費を避けるためにも使われました。最初の問題は PHP の最小バージョンが 5.2 になり無関係になっており2番目の問題はコメントのストリッピング機能をシミュレートした正規表現を削除することですでに修正されています。 
     128  * `strip_comments`: `strip_comments` は PHP 5.0.x のトークナイザーのバグが原因のコメント除外機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかったとき、メモリの大量消費を避けるためにも使われていました。最初の問題は PHP の最小バージョンが 5.2 になり無関係になっており2番目の問題はコメント除外機能をシミュレートした正規表現を削除することですでに修正されています。 
    129129 
    130130  * `lazy_routes_deserialize`: このオプションはもう必要ありません。 
    …… 
    137137    `validation_error_class`、`validation_error_id_prefix`: これらの設定は Validation ヘルパーグループによって使われ、symfony 1.3 で廃止予定です。 
    138138 
    139   * `is_internal` (`module.yml`): `is_internal` フラグはブラウザーからアクションが呼び出されるのを防ぐために使われました。これは symfony 1.0 でメール送信を保護するために追加されました。メールのサポートはこのトリックを必要としなくなったので、このフラグは削除され symfony コアではチェックされません。 
     139  * `is_internal` (`module.yml`): `is_internal` フラグはブラウザーからアクションが呼び出されるのを防ぐために使われました。これは symfony 1.0 でメール送信を保護するために追加されました。メールのサポートにこのトリックが必要なくなったので、このフラグは削除され symfony コアではチェックされません。 
    140140 
    141141タスク 
    142142------ 
    143143 
    144 次のタスクは symfony 1.3 で削除されました: 
     144次のタスクが symfony 1.3 で削除されます: 
    145145 
    146146  * `project:freeze` と `project:unfreeze`: これらのタスクはプロジェクトによって使われる symfony のバージョンをプロジェクト自身の内部に組み込むために使われました。これらはもはや必要ありません。長期間に渡って symfony をプロジェクトに組み込むのがベストプラクティスになったからです。さらに、あるバージョンの symfony を別のバージョンに切り替える作業は本当に単純で必要なのは `ProjectConfiguration` クラスへのパスを変更することだけです。symfony を手作業で組み込むやり方もとても単純で symfony のディレクトリ全体をプロジェクトのどこかにコピーすることだけ必要です (`lib/vendor/symfony/` が推奨されます)。 
    …… 
    168168  * `sfParameterHolder::get()`、`sfParameterHolder::has()`、 
    169169    `sfParameterHolder::remove()`、`sfNamespacedParameterHolder::get()`、 
    170     `sfNamespacedParameterHolder::has()` と `sfNamespacedParameterHolder::remove()` メソッドは配列表記 (`[]`) をサポートし廃止予定で symfony 1.4 では利用できません (パフォーマンスの向上)。 
     170    `sfNamespacedParameterHolder::has()` と `sfNamespacedParameterHolder::remove()` メソッドの配列表記 (`[]`) のサポートは廃止予定になり symfony 1.4 では利用できません (パフォーマンスの向上)。 
    171171 
    172172symfony CLI はグローバルな `--dry-run` オプションを受けとることはありません。このオプションは symfony の組み込みタスクによって使われていなかったからです。タスクの 1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。 
    …… 
    1741741.0 のアドミンジェネレーターの Propel テンプレートと 1.0 の CRUD は symfony 1.4 で削除されます (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。 
    175175 
    176 「Dynarch Calendar」 (`data/web/calendar/` で見つかります) は symfony 1.4 は削除されます。これは symfony 1.4 で削除される Form ヘルパーグループだけしか使っていたからです。 
     176「Dynarch Calendar」 (`data/web/calendar/` で見つかります) は symfony 1.4 は削除されます。これは symfony 1.4 で削除される Form ヘルパーグループだけにしか使われていなかったからです。 
    177177 
    178178symfony 1.3 に関して、サイトが利用不可能なときに表示されるページは `%SF_APP_CONFIG_DIR%/` と `%SF_CONFIG_DIR%/` ディレクトリでのみ探されます。まだこれを `%SF_WEB_DIR%/errors/` に保存している場合、symfony 1.4 へのマイグレーションを行う前に削除しなければなりません。 
    179179 
    180 プロジェクトのルートで `doc/` ディレクトリは生成されなくなりました。これは symfony 自身でも使われていないからです。そして関連する `sf_doc_dir` も削除されました。 
     180プロジェクトのルートで `doc/` ディレクトリが生成されなくなりました。これは symfony 自身でも使われていないからです。そして関連する `sf_doc_dir` も削除されました。 
    181181 
    182182`sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、1.3 で廃止予定になり 1.4 で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。 
    183183 
    184 symfony のすべての `Base*` クラスの可視性は `abstract` になっていません。 
     184symfony のすべての `Base*` クラスの可視性は `abstract` ではありません。 

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

    r28343 r28384  
    119119 * すでによりすぐれた、シンプルで、より柔軟な解決方法があります (`include_stylesheets()` と `include_javascripts()` ヘルパー)。 
    120120 
    121  * フィルターが簡単に無効にできるとしても、最初に存在を知らなければならず"背後"のマジックがはたらいているのでこれは簡単なタスクではありません。 
     121 * フィルターが簡単に無効にできるとしても、最初に存在を知らなければならず「背後」のマジックがはたらいているのでこれは簡単なタスクではありません。 
    122122 
    123123 * ヘルパーを使えばいつどこでアセットがレイアウトにインクルードされるのかよりきめ細かくコントロールできます (たとえば `head` タグのスタイルシート、`body` タグが終わる直前の JavaScript) 
    …… 
    209209以前のコンフィギュレーションでは、メールは送信されません。もちろん、これらはまだロギングされ、`mailer` テスターは機能テストでまだ動きます。 
    210210 
    211 1 つのアドレスですべてのメールを受信したいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境): 
     2111つのアドレスですべてのメールを受信したいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境): 
    212212 
    213213    [yml] 

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

    r28343 r28384  
    1919    $this->getMailer()->composeAndSend('from@example.com', 'to@example.com', 'Subject', 'Body'); 
    2020 
    21 より柔軟性をもたせる必要があれば、`compose()` メソッドを使って後で送信することもできます。添付ファイルをメッセージに追加する方法は次の通りです: 
     21より柔軟性をもたせる必要があれば、`compose()` メソッドを使って後で送信することもできます。添付ファイルをメッセージに追加する方法は次のとおりです: 
    2222 
    2323    [php] 
    …… 
    6262  * `sfWidgetFormI18nChoiceTimezone` 
    6363 
    64 これらの最初の 3つは廃止予定の `sfWidgetFormI18nSelectLanguage`、`sfWidgetFormI18nSelectCurrency` と `sfWidgetFormI18nSelectCountry` ウィジェットの置き換えです。 
     64これらの最初の3つは廃止予定の `sfWidgetFormI18nSelectLanguage`、`sfWidgetFormI18nSelectCurrency` と `sfWidgetFormI18nSelectCountry` ウィジェットの置き換えです。 
    6565 
    6666### 流れるようなインターフェイス 
    …… 
    8787`sfValidatorRegex` に新しい `must_match` オプションが用意されました。このオプションが `false` にセットされる場合、正規表現は渡すバリデーターにマッチしません。 
    8888 
    89 `sfValidatorRegex` の `pattern` オプションは呼び出すときに正規表現を返す `sfCallable` のインスタンスにしなければならなくなりました。 
     89`sfValidatorRegex` の `pattern` オプションは呼び出されるときに正規表現を返す `sfCallable` のインスタンスにしなければならなくなりました。 
    9090 
    9191### `sfValidatorUrl` 
    …… 
    105105### `sfValidatorSchemaCompare` 
    106106 
    107 `sfValidatorSchemaCompare` クラスに 2つの新しいコンパレーターが用意されました: 
     107`sfValidatorSchemaCompare` クラスに2つの新しいコンパレーターが用意されました: 
    108108 
    109109 * `IDENTICAL` は `===` と同等です; 
    …… 
    112112### `sfValidatorChoice`、`sfValidator(Propel|Doctrine)Choice` 
    113113 
    114 `sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデーターには `multiple` オプションが `true` の場合のみ有効になる 2つの新しいオプションがあります: 
     114`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデーターには `multiple` オプションが `true` の場合のみ有効になる2つの新しいオプションがあります: 
    115115 
    116116 * `min` 選択する必要がある最小の数 
    …… 
    123123 * `sfValidatorI18nChoiceTimezone` 
    124124 
    125 ### 標準のエラーメッセージ 
    126  
    127 次のように `sfForm::setDefaultMessage()` メソッドを使うことでグローバル領域で標準のエラーメッセージを定義できるようになりました: 
     125### デフォルトのエラーメッセージ 
     126 
     127次のように `sfForm::setDefaultMessage()` メソッドを使うことでデフォルトのエラーメッセージをグローバルに定義できるようになりました: 
    128128 
    129129    [php] 
    130130    sfValidatorBase::setDefaultMessage('required', 'This field is required.'); 
    131131 
    132 上記のコードはすべてのバリデーターのデフォルトメッセージである 'Required.' をオーバーライドします。標準メッセージはバリデーターが作られる前に定義しておかなければならないことに注意してください (コンフィグレーションクラスがよい場所です)。 
     132上記のコードはすべてのバリデーターのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデーターが作られる前に定義しておかなければならないことにご注意ください (コンフィグレーションクラスがよい場所です)。 
    133133 
    134134>**NOTE** 
    …… 
    137137symfony がエラーを表示するとき、使われるエラーメッセージは次のように決定されます: 
    138138 
    139   * symfony はバリデーターが作られたときに渡されたメッセージを探します (バリデーターのコンストラクターの第 2引数経由); 
     139  * symfony はバリデーターが作られたときに渡されたメッセージを探します (バリデーターのコンストラクターの第2引数経由); 
    140140 
    141141  * 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージを探します; 
    142142 
    143   * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき) バリデーター自身で定義された初期メッセージへ戻ります。 
     143  * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき) バリデーター自身で定義される初期メッセージへ戻ります。 
    144144 
    145145### 流れるようなインターフェイス 
    …… 
    156156### `sfValidatorFile` 
    157157 
    158 `php.ini` で `file_uploads` が無効な場合 `sfValidatorFile` のインスタンスを作成するときに例外が投げられます。 
     158`php.ini` で `file_uploads` が無効な場合 `sfValidatorFile` のインスタンスを作るときに例外が投げられます。 
    159159 
    160160フォーム 
    …… 
    163163### `sfForm::useFields()` 
    164164 
    165 新しい `sfForm::useFields()` メソッドはフォームから引数として提供されるもの以外、隠しフィールドではないフィールドすべてを削除します。状況によって不要なフィールドの割り当てを解除する代わりにフォームで維持したいフィールドを明示的に指示するのが簡単になります。たとえば、新しいフィールドを基底フォームに追加するとき、これらは明示的に追加されるまでフォームに自動表示されなくなります (モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。 
     165新しい `sfForm::useFields()` メソッドはフォームから引数として提供されるもの以外、隠しフィールドではないフィールドすべてを削除します。ときには不要なフィールドの割り当てを解除する代わりにフォームで維持したいフィールドを明示的に指示するのが簡単になります。たとえば、新しいフィールドを基底フォームに追加するとき、これらは明示的に追加されるまでフォームに自動表示されることはありません (モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。 
    166166 
    167167    [php] 
    …… 
    174174    } 
    175175 
    176 デフォルトでは、フィールドの配列はフィールドの順序を変更するのにも使われます。自動的な並べ替えを無効にするには、`useFields()` に 2番目の引数として `false` を 渡します。 
     176デフォルトでは、フィールドの配列はフィールドの順序を変更するのにも使われます。自動的な並べ替えを無効にするには、`useFields()` に2番目の引数として `false` を 渡します。 
    177177 
    178178### `sfForm::getEmbeddedForm($name)` 
    …… 
    182182### `sfForm::renderHiddenFields()` 
    183183 
    184 `->renderHiddenFields()` メソッドは組み込みフォームから隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッターを使って組み込みフォームをレンダリングする場合に便利です。 
     184`->renderHiddenFields()` メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッターを使って組み込みフォームをレンダリングする場合に便利です。 
    185185 
    186186    [php] 
    …… 
    188188    echo $form->renderHiddenFields(); 
    189189 
    190     // 再帰なしで隠しフィールドをレンダリングする 
     190    // 再帰処理なしで隠しフィールドをレンダリングする 
    191191    echo $form->renderHiddenFields(false); 
    192192 
    193193### `sfFormSymfony` 
    194194 
    195 新しい `sfFormSymfony` クラスはイベントディスパッチャーを symfony フォームに導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャーにアクセスできます。次のフォームイベントは symfony によって通知されます: 
     195新しい `sfFormSymfony` クラスはイベントディスパッチャーを symfony フォームに導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャーにアクセスできます。次のフォームイベントが symfony によって通知されます: 
    196196 
    197197  * `form.post_configure`:   このイベントはフォームが設定された後で通知される 
    198198  * `form.filter_values`:    このイベントは、マージされ汚染されたパラメーターと、バインドする直前のファイルの配列をフィルタリングする 
    199199  * `form.validation_error`: フォームバリデーションが通らないときこのイベントが通知される 
    200   * `form.method_not_found`: 不明なメソッドが呼び出されるときにこのイベントが通知される 
     200  * `form.method_not_found`: 身元不明のメソッドが呼び出されるときにこのイベントが通知される 
    201201 
    202202 
    203203### `BaseForm` 
    204204 
    205 Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使うことができる `BaseForm` クラスが symfony 1.3/1.4 のすべての新しいプロジェクトに入りました。`sfDoctrinePlugin` と `sfPropelPlugin` によって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば `sfForm` よりも `BaseForm` を継承すべきです。 
     205Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使うことのできる `BaseForm` クラスが symfony 1.3/1.4 のすべての新しいプロジェクトに入ります。`sfDoctrinePlugin` と `sfPropelPlugin` によって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば `sfForm` ではなく `BaseForm` を継承させるべきです。 
    206206 
    207207### `sfForm::doBind()` 
    …… 
    222222    $this->disableLocalCSRFProtection(); 
    223223 
    224 `disableLocalCSRFProtection()` を呼び出すことによって、フォームインスタンスを作るときに CSRF 対策の秘密の文字列を渡したとしても CSRF 防止機能は無効になります。 
     224`disableLocalCSRFProtection()` を呼び出すことによって、フォームインスタンスを作るときに CSRF 対策の秘密の文字列を渡していたとしても CSRF 防止機能は無効になります。 
    225225 
    226226### 流れるようなインターフェイス 
    …… 
    248248    $ php symfony test:all --only-failed 
    249249 
    250 どのように動くのかを説明します: まず最初に、すべてのテストはいつも通りに実行されます。しかし引き続きテストを実行しても、最後のテストで通らなかったものだけが実行されます。コードを修正したら、テストが通り次回以降の実行から除外されます。再びすべてのテストが通ったら、あなたは完全なテストスイートを実行し、繰り返すことができます。 
     250どのように動くのかを説明します: まず最初に、すべてのテストはいつもどおりに実行されます。しかし引き続きテストを実行しても、最後のテストで通らなかったものだけが実行されます。コードを修正したら、一部のテストが通り次回以降の実行から除外されます。再びすべてのテストが通ったら、あなたは完全なテストスイートを実行し、徹底的に繰り返すことができます。 
    251251 
    252252### 機能テスト 
    …… 
    265265### JUnit と互換性のある XML 出力 
    266266 
    267 `--xml` オプションを使うことでテストタスクは JUnit と互換性のある XML ファイルも出力できるようになりました: 
     267`--xml` オプションをつけることでテストタスクは JUnit と互換性のある XML ファイルも出力できるようになりました: 
    268268 
    269269    $ php symfony test:all --xml=log.xml 
    …… 
    277277### lime によるカラー出力 
    278278 
    279 symfony 1.3/1.4 では、lime はカラー出力を正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクターの第 2 引数を省略できるということです: 
     279symfony 1.3/1.4 では、lime はカラー出力を正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクターの第2引数を省略できるということです: 
    280280 
    281281    [php] 
    …… 
    299299    end(); 
    300300 
    301 レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをピンポイントで指定する CSS セレクターを提供するオプションがあります: 
     301レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクターを提供するオプションがあります: 
    302302 
    303303    [php] 
    …… 
    350350------ 
    351351 
    352 symfony の CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI は幅をデフォルトの 78カラムに合わせようとします。 
     352symfony の CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI は幅をデフォルトの78カラムに合わせようとします。 
    353353 
    354354### `sfTask::askAndValidate()` 
    355355 
    356 ユーザーに質問をして得られた入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新しく用意されました: 
     356ユーザーに質問をして得られる入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新しく用意されました: 
    357357 
    358358    [php] 
    359359    $anwser = $this->askAndValidate('What is you email?', new sfValidatorEmail()); 
    360360 
    361 このメソッドはオプションの配列を受けることもできます (より詳しい情報は API ドキュメントを参照してください)。 
     361このメソッドはオプションの配列を受けることもできます (より詳しい情報は API ドキュメントを参照)。 
    362362 
    363363### `symfony:test` 
    364364 
    365 ときには、開発者は特定のプラットフォームで symfony が正しく動くのかをチェックするために symfony のテストスイートを実行する必要があります。従来は、symfony に附属している `prove.php` スクリプトを実行し確認しなければなりませんでした。symfony 1.3/1.4 では組み込みのタスク、コマンドラインから symfony のコアテストスイートを起動できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます: 
     365ときに開発者は特定のプラットフォームで symfony が正しく動くのかをチェックするために symfony のテストスイートを実行する必要があります。従来であれば、この確認作業を行うために symfony に附属する `prove.php` スクリプトの存在を知らなければなりませんでした。symfony 1.3/1.4 では組み込みのタスク、コマンドラインから symfony のコアテストスイートを起動できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます: 
    366366 
    367367    $ php symfony symfony:test 
    …… 
    372372### `project:deploy` 
    373373 
    374 `project:deply` タスクは少し改良されました。リアルタイムでファイルの転送状況を表示するようになりました。ただし、`-t` オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません、もちろんエラーは除きます。エラーのときには、簡単に問題を認識できるように赤色の背景にエラー情報を出力します。 
     374`project:deply` タスクは少し改良されました。リアルタイムでファイルの転送状況を表示するようになりました。ただし、`-t` オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません、もちろんエラーの場合は除きます。エラーのときには、簡単に問題を認識できるように赤色の背景にエラー情報が出力されます。 
    375375 
    376376### `generate:project` 
    …… 
    388388    $ php /path/to/symfony generate:project foo --orm=none 
    389389 
    390 新しい `--installer` オプションのおかげで新しく生成されるプロジェクトをかなりカスタマイズできる PHP スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドで使うことができます。次のようなより便利なメソッドがあります: 
     390新しい `--installer` オプションのおかげで新たに生成されるプロジェクトをかなりカスタマイズできる PHP スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドで使うことができます。次のようなより便利なメソッドがあります: 
    391391`installDir()`、`runTask()`、`ask()`、 
    392392`askConfirmation()`、`askAndValidate()`、`reloadTasks()`、 
    …… 
    401401### `sfFileSystem::execute()` 
    402402 
    403 `sfFileSystem::execute()` メソッドは `sfFileSystem::sh()` メソッドをより強力な機能に置き換えます。このメソッドは `stdout` と `stderr` 出力のリアルタイム処理のコールバックをとります。また両方の出力を配列として返すこともできます。`sfProjectDeployTask` クラスで使い方の例を見つけることができます。 
     403`sfFileSystem::sh()` メソッドはより強力な機能をもつ `sfFileSystem::execute()` メソッドに置き換わります。このメソッドは `stdout` と `stderr` 出力のリアルタイム処理のコールバックをとります。また両方の出力を配列として返すこともできます。使い方の例は `sfProjectDeployTask` クラスで見つけることができます。 
    404404 
    405405### `task.test.filter_test_files` 
    406406 
    407 `test:*` タスクはこれらのタスクが実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントには `arguments` と `options` パラメーターがあります。 
     407`test:*` タスクはこれらのタスクが実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントには `arguments` と `options` パラメーターが用意されています。 
    408408 
    409409### `sfTask::run()` の強化 
    410410 
    411 `sfTask:run()` に次のような引数とオプションの連想配列を渡すことができるようになりました: 
     411`sfTask:run()` に次のような引数とオプションの連想配列を渡せるようになりました: 
    412412 
    413413    [php] 
    …… 
    419419    )); 
    420420 
    421 これまでのバージョンでは、次のようにすればまだ動きます: 
     421以前のバージョンでは、次のように書けばまだ動きます: 
    422422 
    423423    [php] 
    …… 
    436436    $task->run(); 
    437437 
    438 これまでのバージョンでは、次のようにすればまだ動きます: 
     438以前のバージョンでは、次のように書けばまだ動きます: 
    439439 
    440440    [php] 
    …… 
    447447### `project:disable` と `project:enable` 
    448448 
    449 `project:disable` と `project:enable`タスクを使うことで、環境全体を無効、または有効にすることができるようになりました: 
     449`project:disable` と `project:enable`タスクを使うことで、環境全体を無効、または有効にできるようになりました: 
    450450 
    451451    $ php symfony project:disable prod 
    …… 
    464464### `help` と `list` 
    465465 
    466 `help` と `list` タスクは情報を XML 形式で表示することができるようになりました: 
     466`help` と `list` タスクは情報を XML 形式で表示できるようになりました: 
    467467 
    468468    $ php symfony list --xml 
    …… 
    475475### `project:optimize` 
    476476 
    477 このタスクを実行すればアプリケーションのテンプレートファイルの位置をキャッシュすることで実行時におけるディスクの読み込み回数を減らします。このタスクは運用サーバーでのみ使われます。プロジェクトを変更するたびにタスクを再実行することをお忘れなく。 
     477このタスクを実行すればアプリケーションのテンプレートファイルの位置をキャッシュすることで実行時におけるディスクの読み込み回数を減らします。このタスクは運用サーバーでのみ使うべきです。プロジェクトを変更するたびにタスクを再実行することをお忘れなく。 
    478478 
    479479    $ php symfony project:optimize frontend 
    …… 
    485485### タスクからメールを送信する 
    486486 
    487 `getMailer()` メソッドを使うことでタスクからメールを簡単に送信することができます。 
     487`getMailer()` メソッドを使うことでタスクからメールを簡単に送信することができるようになりました。 
    488488 
    489489### タスクでルーティングを使う 
    490490 
    491 `getRouting()` メソッドを使うことでタスクからルーティングオブジェクトを簡単に得ることができます。 
     491`getRouting()` メソッドを使うことでタスクからルーティングオブジェクトを簡単に得られるようになりました。 
    492492 
    493493例外 
    …… 
    500500### Web デバッグツールバー 
    501501 
    502 可能であれば、開発環境の例外ページで Web デバッグツールバーが表示されます。 
     502可能であれば、開発環境の例外ページでも Web デバッグツールバーが表示されるようになりました。 
    503503 
    504504Propel との統合 
    …… 
    548548            filter: false 
    549549 
    550 この設定が考慮される前にモデルをリビルドしなければならないことに注意してください。これはふるまいがモデルに添付されこれをリビルドした後でのみ存在するからです。 
     550この設定が考慮される前にモデルをリビルドしなければならないことにご注意ください。これはふるまいがモデルに添付されこれをリビルドした後でのみ存在するからです。 
    551551 
    552552### 異なるバージョンの Propel を使う 
    …… 
    596596### データの更新 
    597597 
    598 国際化オペレーションに使われるすべてのデータは `ICU` プロジェクトから更新されました。symfony には約 330個のロケールファイルが付属しており、symfony 1.2 と比べると約 70個増えています。ですのでたとえば、言語リストの 10番目の項目をチェックするテストケースが通らない可能性があることにご注意をお願いします。 
     598国際化オペレーションに使われるすべてのデータは `ICU` プロジェクトから更新されました。symfony には約330個のロケールファイルが付属しており、symfony 1.2 と比べると約70個増えています。ですのでたとえば、言語リストの10番目の項目をチェックするテストケースが通らない可能性があることにご注意をお願いします。 
    599599 
    600600### ユーザーロケールを基準にソートする 
    601601 
    602 このロケールに依存するデータにおけるすべてのソートもロケールに依存して実行されます。この目的のために `sfCultureInfo->sortArray()` を使うことができます。 
     602ユーザーロケールに依存するデータのソートもすべてロケールに依存して実行されます。この目的のために `sfCultureInfo->sortArray()` を使うことができます。 
    603603 
    604604プラグイン 
    …… 
    637637### `sfPluginConfiguration::connectTests()` 
    638638 
    639 新しい `setupPlugins()` メソッドのなかでプラグインコンフィギュレーションの `->connectTests()` メソッドを呼び出すことでプラグインのテストを `test:*` タスクに結びつけることができます。 
     639新しい `setupPlugins()` メソッドのなかでプラグインコンフィギュレーションの `->connectTests()` メソッドを呼び出すことでプラグインのテストを `test:*` タスクにつなげることができます。 
    640640 
    641641    [php] 
    …… 
    655655symfony 1.3/1.4 は可能であればファイルパスをクリック可能なリンク (すなわちデバッグ例外のテンプレート) にフォーマットします。`sf_file_link_format` がセットされている場合、この目的に使われ、そうでなければ、symfony は PHP コンフィギュレーションの `xdebug.file_link_format` の値を探します。 
    656656 
    657 たとえば、TextMate でファイルを開きたい場合、次のコードを `settings.yml` に追加します: 
     657たとえば、ファイルを TextMate で開きたい場合、次のコードを `settings.yml` に追加します: 
    658658 
    659659    [yml] 
    …… 
    671671### フォームクラスを生成する 
    672672 
    673 Doctrine の YAML スキーマファイルのなかで ymfony の追加オプションを指定できるようになりました。そしてフォームとフィルタークラスの生成を無効にするオプションもいくつか追加されました。 
     673Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そしてフォームとフィルタークラスの生成を無効にするオプションもいくつか追加されました。 
    674674 
    675675たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルターフォームクラスを生成させる必要はありません。ですので次のようなことができます: 
    …… 
    696696Doctrine で開発するときに手助けしてくれる新しいタスクが導入されました。 
    697697 
    698 #### モデルテーブルを作成する 
     698#### モデルテーブルを作る 
    699699 
    700700指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するときあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃したくなく単にテーブル群を再構築したいときに役立ちます。 
    …… 
    704704#### モデルファイルを削除する 
    705705 
    706 YAML スキーマファイルのなかでモデルや名前を変更したり、使わなくなったモデルを削除したりすることがよくあるでしょう。このような作業を行ったとき、孤児となったモデル、フォームそしてフィルタークラスが現れます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で掃除することができるようになりました。 
     706YAML スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児となったモデル、フォームそしてフィルタークラスが出てきます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で掃除できるようになりました。 
    707707 
    708708    $ php symfony doctrine:delete-model-files ModelName 
    …… 
    716716    $ php symfony doctrine:clean-model-files 
    717717 
    718 上記コマンドは YAML スキーマファイルと生成モデルやファイルと比較し、どれを削除すべきかを決定します。これらのモデルは `doctrine:delete-model-files` タスクに伝えられます。タスクは自動的に削除する前にどのファイルが削除されるのか確認を求めます。 
     718上記コマンドは YAML スキーマファイルと生成モデルやファイルと比較し、どれを削除するのかを決定します。これらのモデルは `doctrine:delete-model-files` タスクに渡されます。タスクは自動的に削除する前にどのファイルが削除されるのか確認を求めます。 
    719719 
    720720#### 何でもビルドする 
    …… 
    736736これはモデルを生成 (`:build-model`) し、データベースのマイグレーション (`:migrate`) を行い、そしてカテゴリのフィクスチャデータ (`:data-load --append --dir=/data/fixtures/categories.yml`)をつけ加えます。 
    737737 
    738 より多くの情報は `doctrine:build` タスクのヘルプページを参照してください。 
     738詳しい情報は `doctrine:build` タスクのヘルプページを参照してください。 
    739739 
    740740#### 新しいオプション: `--migrate` 
    …… 
    751751#### `doctrine:generate-migration --editor-cmd` 
    752752 
    753 `doctrine:generate-migration` タスクは `--editor-cmd` オプションを受け入れるようになりました。このオプションは編集を楽にするためにマイグレーションクラスが作られると実行されます。 
     753`doctrine:generate-migration` タスクは `--editor-cmd` オプションを受け入れるようになりました。このオプションは編集を楽にするためにありマイグレーションクラスが作られるときに実行されます。 
    754754 
    755755 
    …… 
    770770### 日付のセッターとゲッター 
    771771 
    772 Doctrine の日付とタイムスタンプの値を PHP の DateTime オブジェクトインスタンスとして取得するための 2つの新しいメソッドが追加されました。 
     772Doctrine の日付とタイムスタンプの値を PHP の DateTime オブジェクトインスタンスとして取得するための2つの新しいメソッドが追加されました。 
    773773 
    774774    [php] 
    …… 
    776776      ->format('m/d/Y'); 
    777777 
    778 `setDateTimeObject` メソッドを呼び出し有効な `DateTime` インスタンスを渡すだけで日付の値もセットできます。 
     778`setDateTimeObject` メソッドを呼び出し、有効な `DateTime` インスタンスを渡すだけで日付の値もセットできます。 
    779779 
    780780    [php] 
    …… 
    783783### `doctrine:migrate --down` 
    784784 
    785 `doctrine:migrate` はスキーマをリクエストされる方向に 1回でマイグレートする `up` と `down` オプションを受け入れます。 
     785`doctrine:migrate` はスキーマをリクエストされる方向に1回でマイグレートする `up` と `down` オプションを受け入れます。 
    786786 
    787787    $ php symfony doctrine:migrate --down 
    …… 
    816816### 機能テストでクエリをデバッグする 
    817817 
    818 `sfTesterDoctrine` クラスに `->debug()` メソッドが収録されました。このメソッドは現在のコンテクストで実行されたクエリの情報を出力します。 
     818`sfTesterDoctrine` クラスに `->debug()` メソッドが用意されました。このメソッドは現在のコンテクストで実行されたクエリの情報を出力します。 
    819819 
    820820    [php] 
    …… 
    824824    ; 
    825825 
    826 メソッドに数値を渡すことで直近の実行されたクエリの履歴を見ることができ、文字列を渡すことで文字列の一部にマッチするものや正規表現にマッチするクエリだけを表示することができます。 
     826メソッドに数値を渡すことで直近の実行されたクエリの履歴を見ることができる、もしくは文字列を渡すことで文字列の一部にマッチするものや正規表現にマッチするクエリだけを表示することができます。 
    827827 
    828828    [php] 
    …… 
    841841    )); 
    842842 
    843 `->setTableMethod()` (または `table_method` オプション) を通して指定されたテーブルメソッドはクエリオブジェクトを返す必要がありません。次はどれも有効な `sfFormFilterDoctrine` テーブルメソッドです: 
    844  
    845     [php] 
    846     // symfony >= 1.2 で動作する 
     843`->setTableMethod()` (もしくは `table_method` オプション) を通して指定されたテーブルメソッドはクエリオブジェクトを返す必要がありません。次はどれも有効な `sfFormFilterDoctrine` テーブルメソッドです: 
     844 
     845    [php] 
     846    // symfony >= 1.2 で動く 
    847847    public function getQuery() 
    848848    { 
    …… 
    850850    } 
    851851 
    852     // symfony >= 1.2　で動作する 
     852    // symfony >= 1.2 で動く 
    853853    public function filterQuery(Doctrine_Query $query) 
    854854    { 
    …… 
    856856    } 
    857857 
    858     // symfony >= 1.3　で動作する 
     858    // symfony >= 1.3 で動く 
    859859    public function modifyQuery(Doctrine_Query $query) 
    860860    { 
    …… 
    862862    } 
    863863 
    864 フォームフィルターのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するには、必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 
     864フォームフィルターのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するのに必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 
    865865 
    866866    [php] 
    …… 
    894894### マジックメソッドの PHPDoc タグ 
    895895 
    896 symfony が Doctrine モデルに追加するゲッターとセッターのマジックメソッドはそれぞれの生成基底クラスの PHPDoc ヘッダーに現れます。IDE がコード入力補完をサポートする場合、これらの `getFooBar()` と `setFooBar()` メソッドがモデルオブジェクトに現れることがわかります。`FooBar` はラクダ記法のフィールド名です。 
     896symfony が Doctrine モデルに追加するゲッターとセッターのマジックメソッドはそれぞれの生成基底クラスの PHPDoc ヘッダーに現れます。IDE がコード入力補完をサポートする場合、これらの `getFooBar()` と `setFooBar()` メソッドはモデルオブジェクトで見ることになります。`FooBar` はラクダ記法のフィールド名です。 
    897897 
    898898### 異なるバージョンの Doctrine を使う 
    …… 
    939939---------- 
    940940 
    941 `sfDoctrinePager` と `sfPropelPager` メソッドは `Iterator` と `Countable` インターフェイスを実装しています。 
     941`sfDoctrinePager` と `sfPropelPager` メソッドは `Iterator` と `Countable` インターフェイスを実装するようになりました。 
    942942 
    943943    <?php if (count($pager)): ?> 
    …… 
    956956ビューキャッシュマネージャーは `factories.yml` でパラメーターを受けとります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。 
    957957 
    958 `factories.yml` で 2つのパラメーターが利用できます: 
     958`factories.yml` で2つのパラメーターが利用できます: 
    959959 
    960960  * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメーターで指定されるので、これはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。 
    …… 
    962962  * `cache_key_use_host_name` (デフォルト: true): キャッシュキーがホスト名の部分を含むか指定します。実際には、これはページキャッシュがホスト名に依存するかどうかを伝えます。 
    963963 
    964 ### さらにキャッシュ 
    965  
    966 ビューキャッシュマネージャーは配列の `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否することはありません。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことは次のページがキャッシュ可能であることを意味します: 
     964### キャッシュの強化 
     965 
     966ビューキャッシュマネージャーは配列の `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことは次のページがキャッシュ可能であることを意味します: 
    967967 
    968968  * `/js/my_compiled_javascript.js?cachebuster123` 
    …… 
    978978### `PUT` と `DELETE` パラメーター 
    979979 
    980 Content-Type が `application/x-www-form-urlencoded` にセットされた `PUT`、`DELETE` HTTP リクエストメソッドが来た場合、symfony は生のボディを解析し、通常の `POST` パラメーターのようにアクセスできるパラメーターを作ります。 
     980Content-Type が `application/x-www-form-urlencoded` にセットされている `PUT`、`DELETE` HTTP リクエストメソッドが来る場合、symfony は生のボディを解析し、通常の `POST` パラメーターのようにアクセスできるパラメーターを作ります。 
    981981 
    982982アクション 
    …… 
    985985### `redirect()` 
    986986 
    987 `sfAction:redirect()` メソッドは symfony 1.2 で導入された `url_for()` の機能と互換性を持つようになりました。 
     987`sfAction:redirect()` メソッドは symfony 1.2 で導入された `url_for()` の機能と互換性をもつようになりました。 
    988988 
    989989    [php] 
    …… 
    10011001### `link_to_if()`、`link_to_unless()` 
    10021002 
    1003 `link_to_if()` と `link_to_unless()` ヘルパーは symfony 1.2 で導入された `link_to()` メソッドと互換性を持つようになりました: 
     1003`link_to_if()` と `link_to_unless()` ヘルパーは symfony 1.2 で導入された `link_to()` メソッドのシグネチャと互換性をもつようになりました: 
    10041004 
    10051005    [php] 
    …… 
    10131013----------- 
    10141014 
    1015 `sfContext` にメソッドを動的に追加するために `context.method_not_found` をリスニングできます。プラグインから遅延ロードファクトリを追加する場合に役立つでしょう。 
     1015`sfContext` にメソッドを動的に追加するために `context.method_not_found` をリスニングできます。プラグインから遅延ロードファクトリを追加する場合に役立ちます。 
    10161016 
    10171017    [php] 

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

    r28343 r28384  
    22================================== 
    33 
    4 symfony 1.3 と symfony 1.4 のドキュメントはまったく同じものです。2つの異なるバージョンでドキュメントが 1 つしかない状況はめったにないことなので、このドキュメントでは 2つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をどのようにするのかを説明します。 
     4symfony 1.3 と symfony 1.4 のドキュメントはまったく同じものです。2つの異なるバージョンでドキュメントが1つしかない状況はめったにないことなので、このドキュメントでは2つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をどのようにするのかを説明します。 
    55 
    66symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年末) にリリースされ、実際のところ、これらは両方とも**まったく同じ機能一式**を備えています。2つのバージョンの唯一の違いは symfony の古いバージョンとの後方互換性のサポート状況です。 
    …… 
    88symfony 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このドキュメントは廃止予定の機能を説明しないので、すべての例は両方のバージョンで等しく動きます。