Changeset 28427
- Timestamp:
- 03/09/10 11:39:29 (3 years ago)
- Files:
-
- doc/branches/1.4/tutorial/ja/deprecated.markdown (modified) (10 diffs)
- doc/branches/1.4/tutorial/ja/upgrade.markdown (modified) (11 diffs)
- doc/branches/1.4/tutorial/ja/whats-new.markdown (modified) (30 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
doc/branches/1.4/tutorial/ja/deprecated.markdown
r28384 r28427 1 1.3 での廃止予定および削除される機能2 ==================================== 1 1.3での廃止予定および削除される機能 2 ===================================== 3 3 4 4 このドキュメントでは symfony 1.3 で廃止予定もしくは削除されるすべての設定、クラス、メソッド、関数とタスクの一覧を示します。 … … 9 9 次のコアプラグインは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 10 10 11 * `sfCompat10Plugin`: このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0 のアドミンジェネレータ ーとフォームシステム)。これらのなかには `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される 1.0 のアドミンジェネレーターのデフォルトテーマも含まれています。11 * `sfCompat10Plugin`: このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0 のアドミンジェネレータとフォームシステム)。これらのなかには `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される1.0 アドミンジェネレータのデフォルトテーマも含まれています。 12 12 13 13 * `sfProtoculousPlugin`: このプラグインによって提供されるヘルパーは控えめな JavaScript をサポートしないので、今後は使うべきではありません。 … … 31 31 * `sfTestFunctionalBase` の次のメソッド: `isRedirected()`、`isStatusCode()`、`responseContains()`、 32 32 `isRequestParameter()`、`isResponseHeader()`、 33 `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは 1.2以降で廃止予定になり、テスタークラスに置き換わります。33 `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは1.2以降で廃止予定になり、テスタークラスに置き換わります。 34 34 35 * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは 1.2以降で廃止予定になり、テスタークラスに置き換わります。35 * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは1.2以降で廃止予定になり、テスタークラスに置き換わります。 36 36 37 37 * `sfFilesystem::sh()`: このメソッド呼び出しはすべて新しい `sfFilesystem::execute()` メソッド呼び出しに置き換わります。このメソッドの戻り値は `stdout` 出力と `stderr` 出力で構成される配列であることに注意してください。 … … 80 80 81 81 * `sfCrudGenerator`、`sfAdminGenerator`、`sfPropelCrudGenerator`、 82 `sfPropelAdminGenerator`: これらのクラスは 1.0 のアドミンジェネレーターで使われていました。82 `sfPropelAdminGenerator`: これらのクラスは1.0のアドミンジェネレータで使われていました。 83 83 84 * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは 1.0のフォームシステムで使われていました。84 * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは1.0のフォームシステムで使われていました。 85 85 86 86 * `sfLoader`: 「メソッドと関数」のセクションを参照してください。 … … 102 102 次のクラスは symfony 1.3 で削除されます: 103 103 104 * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は「プロジェクトを 1.2 から 1.3/1.4 にアップグレードする」の「共通フィルターの削除」を参照してください。104 * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は「プロジェクトを1.2から1.3/1.4にアップグレードする」の「共通フィルタの削除」を参照してください。 105 105 106 106 ヘルパー … … 109 109 次のヘルパーグループは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます: 110 110 111 * `sfCompat10Plugin` によって提供される 1.0のフォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation`111 * `sfCompat10Plugin` によって提供される1.0のフォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` 112 112 113 113 `form_tag()` ヘルパーの所属は `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4 でも利用可能です。 114 114 115 PHP のインクルードパスからヘルパーをロードする機能は 1.3 で廃止予定になり 1.4で削除されます。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに設置しなければなりません。115 PHP のインクルードパスからヘルパーをロードする機能は1.3で廃止予定になり1.4で削除されます。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに設置しなければなりません。 116 116 117 117 設定 … … 126 126 * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善のために導入され、この設定はビューキャッシュのために遅延キャッシュキー生成を有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも呼び出される `sfViewCacheManager::isCacheable()` に頼るひともいました。symfony 1.3 に関して、ふるまいは `sf_lazy_cache_key` が `true` にセットされる場合と同じになります。 127 127 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番目の問題はコメント除外機能をシミュレートした正規表現を削除することですでに修正されています。 129 129 130 130 * `lazy_routes_deserialize`: このオプションはもう必要ありません。 … … 150 150 * symfony 1.0 のすべてのタスクのエイリアス 151 151 152 * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレータ ーモジュールを生成しました。152 * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレータモジュールを生成しました。 153 153 154 154 次の Doctrine タスクは `doctrine:build` にマージされ symfony 1.4 で削除されます: … … 170 170 `sfNamespacedParameterHolder::has()` と `sfNamespacedParameterHolder::remove()` メソッドの配列表記 (`[]`) のサポートは廃止予定になり symfony 1.4 では利用できません (パフォーマンスの向上)。 171 171 172 symfony CLI はグローバルな `--dry-run` オプションを受け とることはありません。このオプションは symfony の組み込みタスクによって使われていなかったからです。タスクの 1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。172 symfony CLI はグローバルな `--dry-run` オプションを受け取ることはありません。このオプションは symfony の組み込みタスクによって使われていなかったからです。タスクの 1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。 173 173 174 1.0 のアドミンジェネレーターの Propel テンプレートと 1.0 の CRUD は symfony 1.4 で削除されます (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。174 1.0のアドミンジェネレータの Propel テンプレートと 1.0 の CRUD は symfony 1.4 で削除されます (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。 175 175 176 176 「Dynarch Calendar」 (`data/web/calendar/` で見つかります) は symfony 1.4 は削除されます。これは symfony 1.4 で削除される Form ヘルパーグループだけにしか使われていなかったからです。 … … 180 180 プロジェクトのルートで `doc/` ディレクトリが生成されなくなりました。これは symfony 自身でも使われていないからです。そして関連する `sf_doc_dir` も削除されました。 181 181 182 `sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、1.3 で廃止予定になり 1.4で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。182 `sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、1.3で廃止予定になり1.4で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。 183 183 184 184 symfony のすべての `Base*` クラスの可視性は `abstract` ではありません。 doc/branches/1.4/tutorial/ja/upgrade.markdown
r28384 r28427 1 プロジェクトを 1.2 から 1.3/1.4にアップグレードする1 プロジェクトを1.2から1.3/1.4にアップグレードする 2 2 =================================================== 3 3 4 このドキュメントでは symfony 1.3/1.4 で行われた変更と 1.2のプロジェクトをアップグレードするために必要な作業を説明します。4 このドキュメントでは symfony 1.3/1.4 で行われた変更と1.2のプロジェクトをアップグレードするために必要な作業を説明します。 5 5 6 6 symfony 1.3 で変更または追加された機能の詳細を知りたければ、[「symfony 1.3/1.4 の新しい機能」](http://www.symfony-project.org/tutorial/1_4/ja/whats-new)のチュートリアルをご覧ください。 … … 12 12 -------------------------------- 13 13 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 16 1.4にアップグレードする前に、`project:validate` タスクを実行することで廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われてないことを検証することもできます: 17 17 18 18 $ php symfony project:validate … … 20 20 このタスクは symfony 1.4 に切り替える前に変更する必要のあるすべてのファイルの一覧を表示します。 21 21 22 このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。「1.3 の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。22 このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。「1.3の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。 23 23 24 24 >**NOTE** 25 >`sfCompat10Plugin` と `sfProtoculousPlugin` は 1.4から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。25 >`sfCompat10Plugin` と `sfProtoculousPlugin` は1.4から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。 26 26 27 27 symfony 1.3 にアップグレードするには? … … 61 61 -------------- 62 62 63 symfony 1.3 を開発しているあいだに、いくつかの設定、クラス、メソッド、関数とタスクが廃止予定になるもしくは削除されてきました。詳細な情報は[「1.3 での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。63 symfony 1.3 を開発しているあいだに、いくつかの設定、クラス、メソッド、関数とタスクが廃止予定になるもしくは削除されてきました。詳細な情報は[「1.3での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。 64 64 65 65 オートロード機能 … … 79 79 * すでにオートロードメカニズムがはたらく `lib/vendor/` ディレクトリの下でライブラリを設置する場合、symfony はファイルを再解析してキャッシュに不要なたくさんの情報を追加します (#5893 - http://trac.symfony-project.org/ticket/5893 を参照)。 80 80 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 を参照)。 82 82 83 83 symfony 1.3 のオートロード機能は大文字と小文字を区別しません。 … … 91 91 `lazy_routes_deserialize` オプションはもはや必要ないので削除されました。 92 92 93 symfony 1.3 に関しては、ルーティングキャッシュが無効になりました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3 にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。symfony 1.2 のデフォルトコンフィギュレーションに戻すために `factories.yml` に追加する内容は次のとおりです:93 symfony 1.3 に関しては、ルーティングキャッシュが無効になりました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。symfony 1.2 のデフォルトコンフィギュレーションに戻すために `factories.yml` に追加する内容は次のとおりです: 94 94 95 95 [yml] … … 107 107 -------------------------- 108 108 109 ### 共通フィルタ ーの削除110 111 `sfCommonFilter` は削除されデフォルトでは使われていません。このフィルタ ーは自動的に JavaScript とスタイルシートのタグをレスポンスのコンテンツに注入していました。レイアウトのなかで `include_stylesheets()` と `include_javascripts()` ヘルパーを明示的に呼び出すことでこれらのアセットを手動でインクルードする必要があります:109 ### 共通フィルタの削除 110 111 `sfCommonFilter` は削除されデフォルトでは使われていません。このフィルタは自動的に JavaScript とスタイルシートのタグをレスポンスのコンテンツに注入していました。レイアウトのなかで `include_stylesheets()` と `include_javascripts()` ヘルパーを明示的に呼び出すことでこれらのアセットを手動でインクルードする必要があります: 112 112 113 113 [php] … … 119 119 * すでによりすぐれた、シンプルで、より柔軟な解決方法があります (`include_stylesheets()` と `include_javascripts()` ヘルパー)。 120 120 121 * フィルタ ーが簡単に無効にできるとしても、最初に存在を知らなければならず「背後」のマジックがはたらいているのでこれは簡単なタスクではありません。121 * フィルタが簡単に無効にできるとしても、最初に存在を知らなければならず「背後」のマジックがはたらいているのでこれは簡単なタスクではありません。 122 122 123 123 * ヘルパーを使えばいつどこでアセットがレイアウトにインクルードされるのかよりきめ細かくコントロールできます (たとえば `head` タグのスタイルシート、`body` タグが終わる直前の JavaScript) … … 129 129 アップグレードするには? 130 130 131 * すべての `filters.yml` 設定ファイルから `common` フィルタ ーを削除する必要があります (これは `project:upgrade1.3` タスクによって自動的に行われます)。132 133 * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (これはアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の `project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグを 持たなければなりません; ほかのレイアウト、もしくはレイアウトを持たないが JavaScript ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。131 * すべての `filters.yml` 設定ファイルから `common` フィルタを削除する必要があります (これは `project:upgrade1.3` タスクによって自動的に行われます)。 132 133 * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (これはアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の `project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグをもたなければなりません; ほかのレイアウト、もしくはレイアウトをもたないが JavaScript ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。 134 134 135 135 … … 151 151 `sfPropelDumpDataTask` | `sfPropelDataDumpTask` 152 152 153 ### フォーマッタ ー154 155 `sfFormatter::format()` の 3番目の引数は削除されました。153 ### フォーマッタ 154 155 `sfFormatter::format()` の3番目の引数は削除されました。 156 156 157 157 エスケーピング 158 158 ------------- 159 159 160 `ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が `37` から `177`である文字のみがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) のみをエスケープします。160 `ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が`37`から`177`である文字のみがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) のみをエスケープします。 161 161 162 162 Doctrine との統合 … … 167 167 Doctrine の svn:externals は最新の Doctrine 1.2 を使うように更新されました。Doctrine 1.2 の新しい機能に関しては[公式サイトの手引き](http://www.doctrine-project.org/upgrade/1_2)をご覧ください。 168 168 169 ### アドミンジェネレータ ーの削除機能170 171 アドミンジェネレータ ーバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに `delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。169 ### アドミンジェネレータの削除機能 170 171 アドミンジェネレータバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに `delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。 172 172 173 173 ### Doctrine プラグインスキーマをオーバーライドする doc/branches/1.4/tutorial/ja/whats-new.markdown
r28384 r28427 6 6 最初に、symfony 1.3/1.4 は PHP 5.2.4 およびそれ以降のバージョンと互換性があることにご注意ください。 7 7 8 1.2 からアップグレードしたいのであれば、[「プロジェクトを 1.2 から 1.3/1.4にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。8 1.2 からアップグレードしたいのであれば、[「プロジェクトを1.2から1.3/1.4にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。 9 9 10 10 … … 44 44 ### 標準のラベル 45 45 46 ラベルがフィールド名で自動生成される場合、 サフィックスの `_id` は削除されます:46 ラベルがフィールド名で自動生成される場合、接尾辞の `_id` は削除されます: 47 47 48 48 * `first_name` => First name (以前と同じ) … … 80 80 `setLabels()`、`setHelps()`、`setHelp()`、`setParent()`、`setPositions()` 81 81 82 バリデータ ー82 バリデータ 83 83 ------------ 84 84 85 85 ### `sfValidatorRegex` 86 86 87 `sfValidatorRegex` に新しい `must_match` オプションが用意されました。このオプションが `false` にセットされる場合、正規表現は渡すバリデータ ーにマッチしません。87 `sfValidatorRegex` に新しい `must_match` オプションが用意されました。このオプションが `false` にセットされる場合、正規表現は渡すバリデータにマッチしません。 88 88 89 89 `sfValidatorRegex` の `pattern` オプションは呼び出されるときに正規表現を返す `sfCallable` のインスタンスにしなければならなくなりました。 … … 105 105 ### `sfValidatorSchemaCompare` 106 106 107 `sfValidatorSchemaCompare` クラスに2つの新しいコンパレータ ーが用意されました:107 `sfValidatorSchemaCompare` クラスに2つの新しいコンパレータが用意されました: 108 108 109 109 * `IDENTICAL` は `===` と同等です; … … 112 112 ### `sfValidatorChoice`、`sfValidator(Propel|Doctrine)Choice` 113 113 114 `sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデータ ーには `multiple` オプションが `true` の場合のみ有効になる2つの新しいオプションがあります:114 `sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデータには `multiple` オプションが `true` の場合のみ有効になる2つの新しいオプションがあります: 115 115 116 116 * `min` 選択する必要がある最小の数 117 117 * `max` 選択する必要がある最大の数 118 118 119 ### 国際化バリデータ ー120 121 次のバリデータ ーが追加されました:119 ### 国際化バリデータ 120 121 次のバリデータが追加されました: 122 122 123 123 * `sfValidatorI18nChoiceTimezone` … … 130 130 sfValidatorBase::setDefaultMessage('required', 'This field is required.'); 131 131 132 上記のコードはすべてのバリデータ ーのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデーターが作られる前に定義しておかなければならないことにご注意ください (コンフィグレーションクラスがよい場所です)。132 上記のコードはすべてのバリデータのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデータが作られる前に定義しておかなければならないことにご注意ください (コンフィグレーションクラスがよい場所です)。 133 133 134 134 >**NOTE** … … 137 137 symfony がエラーを表示するとき、使われるエラーメッセージは次のように決定されます: 138 138 139 * symfony はバリデータ ーが作られたときに渡されたメッセージを探します (バリデーターのコンストラクターの第2引数経由);139 * symfony はバリデータが作られたときに渡されたメッセージを探します (バリデータのコンストラクタの第2引数経由); 140 140 141 141 * 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージを探します; 142 142 143 * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき) バリデータ ー自身で定義される初期メッセージへ戻ります。143 * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき) バリデータ自身で定義される初期メッセージへ戻ります。 144 144 145 145 ### 流れるようなインターフェイス 146 146 147 バリデータ ーは次のような流れるようなインターフェイスを実装するようになりました:147 バリデータは次のような流れるようなインターフェイスを実装するようになりました: 148 148 149 149 * `sfValidatorSchema`: `setPreValidator()`、`setPostValidator()` … … 182 182 ### `sfForm::renderHiddenFields()` 183 183 184 `->renderHiddenFields()` メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッタ ーを使って組み込みフォームをレンダリングする場合に便利です。184 `->renderHiddenFields()` メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッタを使って組み込みフォームをレンダリングする場合に便利です。 185 185 186 186 [php] … … 193 193 ### `sfFormSymfony` 194 194 195 新しい `sfFormSymfony` クラスはイベントディスパッチャ ーを symfony フォームに導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャーにアクセスできます。次のフォームイベントが symfony によって通知されます:195 新しい `sfFormSymfony` クラスはイベントディスパッチャを symfony フォームに導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャにアクセスできます。次のフォームイベントが symfony によって通知されます: 196 196 197 197 * `form.post_configure`: このイベントはフォームが設定された後で通知される 198 * `form.filter_values`: このイベントは、マージされ汚染されたパラメータ ーと、バインドする直前のファイルの配列をフィルタリングする198 * `form.filter_values`: このイベントは、マージされ汚染されたパラメータと、バインドする直前のファイルの配列をフィルタリングする 199 199 * `form.validation_error`: フォームバリデーションが通らないときこのイベントが通知される 200 200 * `form.method_not_found`: 身元不明のメソッドが呼び出されるときにこのイベントが通知される … … 207 207 ### `sfForm::doBind()` 208 208 209 汚染されたパラメータ ーのクリーニングは開発者にわかりやすい `->doBind()` メソッドに隔離されました。このメソッドは `->bind()` からのパラメーターとファイルのマージされる配列を受けとります。209 汚染されたパラメータのクリーニングは開発者にわかりやすい `->doBind()` メソッドに隔離されました。このメソッドは `->bind()` からのパラメータとファイルのマージされる配列を受けとります。 210 210 211 211 ### `sfForm(Doctrine|Propel)::doUpdateObject()` … … 230 230 `setWidgetSchema()`、`setOption()`、`setDefault()`、そして `setDefaults()` 231 231 232 オートローダ ー232 オートローダ 233 233 -------------- 234 234 235 symfony のすべてのオートローダ ーは大文字と小文字を区別しないようになりました。PHP が大文字と小文字を区別をしないので、symfony もそれに合わせることにしたからです。235 symfony のすべてのオートローダは大文字と小文字を区別しないようになりました。PHP が大文字と小文字を区別をしないので、symfony もそれに合わせることにしたからです。 236 236 237 237 ### `sfAutoloadAgain` (実験的な機能) 238 238 239 デバッグモードでの用途を目的とする特殊なオートローダ ーが追加されました。新しい `sfAutoloadAgain` クラスは symfony の標準オートローダーをリロードし該当するクラスを求めてファイルシステムを検索します。純粋な効果は新しいクラスをプロジェクトに追加した後に `symfony cc` を実行する必要がなくなることです。239 デバッグモードでの用途を目的とする特殊なオートローダが追加されました。新しい `sfAutoloadAgain` クラスは symfony の標準オートローダをリロードし該当するクラスを求めてファイルシステムを検索します。純粋な効果は新しいクラスをプロジェクトに追加した後に `symfony cc` を実行する必要がなくなることです。 240 240 241 241 テスト … … 277 277 ### lime によるカラー出力 278 278 279 symfony 1.3/1.4 では、lime はカラー出力を正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクタ ーの第2引数を省略できるということです:279 symfony 1.3/1.4 では、lime はカラー出力を正しく行うようになりました。これが意味することは、ほとんどの場合において `lime_test` の lime コンストラクタの第2引数を省略できるということです: 280 280 281 281 [php] … … 299 299 end(); 300 300 301 レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクタ ーを提供するオプションがあります:301 レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクタを提供するオプションがあります: 302 302 303 303 [php] … … 339 339 ### 改良された `->click()` 340 340 341 `->click()` メソッドに CSS セレクタ ーを渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になりました。341 `->click()` メソッドに CSS セレクタを渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になりました。 342 342 343 343 [php] … … 405 405 ### `task.test.filter_test_files` 406 406 407 `test:*` タスクはこれらのタスクが実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントには `arguments` と `options` パラメータ ーが用意されています。407 `test:*` タスクはこれらのタスクが実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントには `arguments` と `options` パラメータが用意されています。 408 408 409 409 ### `sfTask::run()` の強化 … … 505 505 --------------- 506 506 507 Propel のバージョンは 1.4にアップグレードされました。Propel のアップグレードに関する詳しい情報は[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。507 Propel のバージョンは1.4にアップグレードされました。Propel のアップグレードに関する詳しい情報は[公式サイト](http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4)を訪問してくださるようお願いします。 508 508 509 509 ### Propel のビヘイビア … … 539 539 ### フォーム生成を無効にする 540 540 541 Propel の `symfony` ビヘイビアにパラメータ ーを渡すことで特定のモデルでのフォーム生成を無効にできます:541 Propel の `symfony` ビヘイビアにパラメータを渡すことで特定のモデルでのフォーム生成を無効にできます: 542 542 543 543 classes: … … 573 573 ### `sfObjectRouteCollection` オプション 574 574 575 新しい `default_params` オプションが `sfObjectRouteCollection` に追加されました。これはそれぞれの生成ルートにデフォルトパラメータ ーを登録することを可能にします:575 新しい `default_params` オプションが `sfObjectRouteCollection` に追加されました。これはそれぞれの生成ルートにデフォルトパラメータを登録することを可能にします: 576 576 577 577 [yml] … … 633 633 634 634 >**NOTE** 635 >1.2 からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが `ProjectConfiguration` ファイルを変更しないからです。このふるまいの変更は symfony 1.3/1.4 の新規プロジェクトのみです。635 >1.2からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが `ProjectConfiguration` ファイルを変更しないからです。このふるまいの変更は symfony 1.3/1.4 の新規プロジェクトのみです。 636 636 637 637 ### `sfPluginConfiguration::connectTests()` … … 662 662 file_link_format: txmt://open?url=file://%f&line=%l 663 663 664 `%f` プレースホルダ ーはファイルの絶対パスに、`%l` プレースホルダーは行数に置き換わります。664 `%f` プレースホルダはファイルの絶対パスに、`%l` プレースホルダは行数に置き換わります。 665 665 666 666 Doctrine との統合 … … 671 671 ### フォームクラスを生成する 672 672 673 Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そしてフォームとフィルタ ークラスの生成を無効にするオプションもいくつか追加されました。674 675 たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタ ーフォームクラスを生成させる必要はありません。ですので次のようなことができます:673 Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そしてフォームとフィルタクラスの生成を無効にするオプションもいくつか追加されました。 674 675 たとえば、 典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので次のようなことができます: 676 676 677 677 UserGroup: … … 704 704 #### モデルファイルを削除する 705 705 706 YAML スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児となったモデル、フォームそしてフィルタ ークラスが出てきます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で掃除できるようになりました。706 YAML スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児となったモデル、フォームそしてフィルタクラスが出てきます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で掃除できるようになりました。 707 707 708 708 $ php symfony doctrine:delete-model-files ModelName … … 730 730 $ php symfony doctrine:build --all-classes --and-migrate 731 731 732 これはモデル (`:build-model`)、フォーム (`:build-forms`)、フォームフィルタ ー(`:build-filters`) を生成し、保留されているマイグレーション (`:migrate`) を実行します。732 これはモデル (`:build-model`)、フォーム (`:build-forms`)、フォームフィルタ (`:build-filters`) を生成し、保留されているマイグレーション (`:migrate`) を実行します。 733 733 734 734 $ php symfony doctrine:build --model --and-migrate --and-append=data/fixtures/categories.yml … … 808 808 (2 results) 809 809 810 ### クエリパラメータ ーを `doctrine:dql` に渡す811 812 `doctrine:dql` タスクもクエリパラメータ ーを引数として受け取れるよう強化されました:810 ### クエリパラメータを `doctrine:dql` に渡す 811 812 `doctrine:dql` タスクもクエリパラメータを引数として受け取れるよう強化されました: 813 813 814 814 $ php symfony doctrine:dql "FROM Article a WHERE name LIKE ?" John% … … 862 862 } 863 863 864 フォームフィルタ ーのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するのに必要なのはウィジェットとそれを処理するメソッドを追加することだけです。864 フォームフィルタのカスタマイズが簡単になりました。フィルタリングをフィールドに追加するのに必要なのはウィジェットとそれを処理するメソッドを追加することだけです。 865 865 866 866 [php] … … 909 909 } 910 910 911 Webデバッグツールバー912 ---------------------- 911 ウェブデバッグツールバー 912 -------------------------- 913 913 914 914 ### `sfWebDebugPanel::setStatus()` 915 915 916 Webデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO` よりも優先順位が高いメッセージがロギングされる場合、log パネルのタイトルの背景色は変わります。917 918 ### `sfWebDebugPanel` リクエストパラメータ ー919 920 `sfWebDebugPanel` パラメータ ーを URL につけ加えることでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config パネルを開くように Webデバッグツールバーはレンダリングされます。921 922 パネルは Web デバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータ ーをインスペクトします:916 ウェブデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO` よりも優先順位が高いメッセージがロギングされる場合、log パネルのタイトルの背景色は変わります。 917 918 ### `sfWebDebugPanel` リクエストパラメータ 919 920 `sfWebDebugPanel` パラメータを URL につけ加えることでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config パネルを開くように ウェブデバッグツールバーはレンダリングされます。 921 922 パネルは Web デバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータをインスペクトします: 923 923 924 924 [php] … … 930 930 ### スロットの改善 931 931 932 スロットが提供されない場合、`get_slot()` と `include_slot()` ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための 2番目のパラメーターを受けとります:932 スロットが提供されない場合、`get_slot()` と `include_slot()` ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための2番目のパラメータを受けとります: 933 933 934 934 [php] … … 952 952 953 953 ビューキャッシュ 954 --------------- 955 956 ビューキャッシュマネージャ ーは `factories.yml` でパラメーターを受けとります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。957 958 `factories.yml` で2つのパラメータ ーが利用できます:959 960 * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメータ ーで指定されるので、これはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。954 ----------------- 955 956 ビューキャッシュマネージャは `factories.yml` でパラメータを受けとります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。 957 958 `factories.yml` で2つのパラメータが利用できます: 959 960 * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメータで指定されるので、これはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。 961 961 962 962 * `cache_key_use_host_name` (デフォルト: true): キャッシュキーがホスト名の部分を含むか指定します。実際には、これはページキャッシュがホスト名に依存するかどうかを伝えます。 … … 964 964 ### キャッシュの強化 965 965 966 ビューキャッシュマネージャ ーは配列の `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことは次のページがキャッシュ可能であることを意味します:966 ビューキャッシュマネージャは配列の `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことは次のページがキャッシュ可能であることを意味します: 967 967 968 968 * `/js/my_compiled_javascript.js?cachebuster123` … … 976 976 リクエストの内容は `getContent()` メソッドを通してアクセスできるようになりました。 977 977 978 ### `PUT` と `DELETE` パラメータ ー979 980 Content-Type が `application/x-www-form-urlencoded` にセットされている `PUT`、`DELETE` HTTP リクエストメソッドが来る場合、symfony は生のボディを解析し、通常の `POST` パラメータ ーのようにアクセスできるパラメーターを作ります。978 ### `PUT` と `DELETE` パラメータ 979 980 Content-Type が `application/x-www-form-urlencoded` にセットされている `PUT`、`DELETE` HTTP リクエストメソッドが来る場合、symfony は生のボディを解析し、通常の `POST` パラメータのようにアクセスできるパラメータを作ります。 981 981 982 982 アクション