diff --git a/more-with-symfony/ja/translators.markdown b/more-with-symfony/ja/translators.markdown index de0719c..f4a5459 100644 --- a/more-with-symfony/ja/translators.markdown +++ b/more-with-symfony/ja/translators.markdown @@ -71,10 +71,18 @@ Yoshihiro TAKAHARA (高原 芳浩) **Twitter**: *http://twitter.com/tumf* +Tomohiro MITSUMUNE (光宗 朋宏) +------------------------------ +[株式会社カカクコム](http://corporate.kakaku.com/)のエンジニア。[写真共有サイトPHOTOHITO](http://photohito.com/)のメイン開発者。symfony には0.6.4の頃から触れている。そろそろ新しいフレームワークを触ってみたいと思っており、Symfony2 と Ruby on Rails3.0 が気になっている。 + +**Web サイト**: *http://d.hatena.ne.jp/Kiske* + +**Twitter**: *http://twitter.com/Kiske* + Masaki Kagaya (加賀谷 昌樹) --------------------------- -PHP エンジニアおよび翻訳者としての修行を積むために MediaWiki、symfony および Doctrine の公式マニュアルの翻訳に携わる。2010年より PHP 公式マニュアルの翻訳を始める。 +PHP エンジニアおよび翻訳者としての修行を積むために MediaWiki、symfony および Doctrine の公式マニュアルの翻訳に携わる。 **Web サイト**: *http://sarabande.jp* diff --git a/reference/ja/01-Introduction.markdown b/reference/ja/01-Introduction.markdown index 66045f1..47b3937 100644 --- a/reference/ja/01-Introduction.markdown +++ b/reference/ja/01-Introduction.markdown @@ -1,12 +1,12 @@ まえがき ======== -Web 開発の速度と効率を上げる方法のなかで、もっとも簡単なのは symfony のようなフルスタックフレームワークを利用することです。 +Web 開発を効率よく進める方法のなかで、もっともかんたんなのは symfony のようなフルスタックフレームワークを利用することです。 -フレームワークにはたくさんの便利な機能が搭載されており、別のオブジェクトページャやデータベース抽象化レイヤーの実装に取り組まずに、ビジネスロジックに専念できるよう手助けしてくれます。しかしながら、学習コストもかかります。すべての組み込み機能とあり得るすべてのコンフィギュレーションを一夜で学ぶことはできません。 +フレームワークの機能は充実しているので、オブジェクトページャやデータベース抽象化レイヤーの実装に取り組まなくても、ビジネスロジックに専念できます。しかしながら、勉強する時間が必要になります。すべての組み込み機能とありうるすべてのコンフィギュレーションを一夜で学ぶことはできません。 -「[*実践 symfony*](http://www.symfony-project.org/jobeet/)」は、初心者が symfony を学び、Web 開発のベストプラクティスの実践を理解するためのすばらしい教材です。 +symfony の初心者の方には、まず最初に「[*実践 symfony*](http://www.symfony-project.org/jobeet/)」を読むことをおすすめします。Web 開発におけるベストプラクティスの実践もこの本から学ぶことができます。 -プロジェクトを始めるとき、質問にすぐ答えてくれるリファレンスガイドが手元に必要です。「*symfony リファレンスガイド*」はこのような案内をすることを目的とした本であり、「*実践 symfony*」の内容を補います。symfony を使って開発をするときはこの本をいつも手元に置きましょう。詳細な目次、用語の索引、各章の相互参照、表などのおかげで、調べたいコンフィギュレーションがすぐに見つかります。 +symfony による開発プロジェクトをはじめるとき、質問にすぐ答えてくれるリファレンスガイドが手元に必要です。「*symfony リファレンスガイド*」はこの目的のために書かれた本で、「*実践 symfony*」の内容を補います。symfony を使って開発をするときはいつもこの本を手元に置きましょう。詳細な目次、用語の索引、各章の相互参照、表などのおかげで、調べたいコンフィギュレーションはすぐに見つかります。 -筆者は symfony のリード開発者ですが、ときどきこの本を読み返して、コンフィギュレーションの特定の設定を探したり、大きなヒントを再発見したりしています。筆者と同じように読者のみなさんが毎日楽しく読んでいただけることを祈っております。 +筆者は symfony のリード開発者ですが、ときどきこの本を読み返して、コンフィギュレーションの特定の設定を探したり、大きなヒントを再発見したりしています。筆者と同じように、読者のみなさんもこの本を毎日楽しく読んでいただけることを願っております。 diff --git a/reference/ja/02-YAML.markdown b/reference/ja/02-YAML.markdown index 43232ed..f221b00 100644 --- a/reference/ja/02-YAML.markdown +++ b/reference/ja/02-YAML.markdown @@ -1,11 +1,11 @@ YAML フォーマット ================ -symfony フレームワークにおいて、設定ファイルの大半は YAML (ヤメル) フォーマットです。[YAML](http://yaml.org/) の公式サイトによれば、YAML は「人間が読みやすいように最適化された、すべてのプログラミング言語のための標準データシリアライゼーション」です。 +symfony フレームワークにおいて、設定ファイルの大半は YAML (ヤメル) で書かれています。[YAML](http://yaml.org/) の公式サイトによれば、YAML とは「人間が読みやすいように最適化された、すべてのプログラミング言語のための標準的なデータシリアライゼーション」です。 -YAML はデータを記述するためのシンプルな言語です。PHP のように、文字列、ブール値、浮動小数点数、整数のようなシンプルなデータ型のための構文をもちます。PHP と異なる点は、配列 (シーケンス) とハッシュ (マッピング) のあいだに違いがあることです。 +YAML はデータを記述するためのシンプルな軽量マークアップ言語です。文字列、ブール値、浮動小数点数、整数のような単純なデータ型をあらわすための構文は PHP と似ています。PHP と異なる構文は配列 (シーケンス) とハッシュ (マッピング) です。 -YAML フォーマットは複雑な入れ子のデータ構造を記述することもできますが、この章では、symfony の設定ファイルを扱うために、YAML について最低限知る必要のある内容だけを説明します。 +複雑なネストのデータ構造も YAML であらわすことができますが、この章では、symfony の設定ファイルを扱うために、YAML について知っておかなければならない最小限の知識を説明します。 スカラー @@ -15,36 +15,34 @@ YAML フォーマットは複雑な入れ子のデータ構造を記述するこ ### 文字列 - [yml] - YAML における文字列 - -- +文字列はシングルクォートかダブルクォートで囲みます。 [yml] - 'YAML におけるシングルクォートで囲まれる文字' + 'シングルクォートで囲まれた文字' >**TIP** ->シングルクォート (`'`) で囲まれる文字列のなかでシングルクォートを表現するには、2つ重ねなければなりません: +>シングルクォート (`'`) で囲まれた文字列のなかでシングルクォートをあらわすには、シングルクォートを2つ連ねます。 > > [yml] -> 'シングルクォートで囲まれる文字列のなかでのシングルクォート '' ' +> 'シングルクォートで囲まれた文字列のなかでのシングルクォート '' ' - [yml] - "YAML におけるダブルクォートの文字列\n" -文字列が1つ以上の適切なスペースで始まるもしくは終わるときは、クォートスタイル (クォートで囲む方法) が便利です。 +文字列が1つ以上の適切なスペースではじまるもしくは終わる場合には、クォートスタイル (クォートで囲む方法) が適しています。 >**TIP** ->ダブルクォートスタイルはエスケープシーケンス (`\`) を使って任意の文字列を表す方法も提供します。文字列に `\n` もしくは Unicode を埋め込むことが必要なときにこのスタイルが重宝します。 +>ダブルクォートスタイルでは任意の文字列をあらわすのにエスケープシーケンス (`\`) を使うこともできます。こちらのスタイルは文字列に `\n` もしくは Unicode を埋め込む場合に適しています。 +> +> [yml] +> "ダブルクォートで囲まれた文字列\n" -文字列に改行を入れるとき、パイプ (`|`) によって示されるリテラルスタイルを選ぶことができます。このスタイルは複数行にわたる文字列を表し、改行は保たれます: +文字列に改行を入れる場合、パイプ (`|`) によって示されるリテラルスタイルを選ぶことができます。このスタイルでは、文字列は複数行にわたってあらわされ、改行は保たれます。 [yml] | \/ /| |\/| | / / | | | |__ -代わりの方法として、文字列を大なり記号 (`>`) で示される折り畳みスタイルで表すことができます。それぞれの改行はスペースに置き換わります: +ほかにも、大なり記号 (`>`) で示される折り畳みスタイルを選ぶことができます。それぞれの改行はスペースに置き換わります。 [yml] > @@ -54,7 +52,7 @@ YAML フォーマットは複雑な入れ子のデータ構造を記述するこ 文字列としてレンダリングされます。 >**NOTE** ->上記の例では、それぞれの行頭にある2つのスペースに注目してください。これらのスペースは出力結果の PHP 文字列には現れません。 +>上記の例では、それぞれの行頭にある2文字分のスペースにご注目ください。これらのスペースは出力結果の PHP 文字列にはあらわれません。 ### 数字 @@ -94,15 +92,15 @@ YAML フォーマットは複雑な入れ子のデータ構造を記述するこ ### null -ヌルの値は `null` もしくはチルダ (`~`) で表されます。 +ヌル (ナル) の値は `null` もしくはチルダ (`~`) であらわします。 ### ブール値 -ブール値は `true` と `false` で表されます。 +ブール値は `true` と `false` であらわします。 ### 日付 -日付の表記は ISO-8601 標準に準拠します: +日付のフォーマットは ISO-8601 標準に準拠します。 [yml] 2001-12-14t21:59:43.10-05:00 @@ -110,49 +108,49 @@ YAML フォーマットは複雑な入れ子のデータ構造を記述するこ - [yml] - # シンプルな日付 + # 単純な日付 2002-12-14 コレクション ------------ -シンプルなスカラーを記述するためだけに YAML ファイルが使われることはほとんどありません。ほとんどの場合、コレクションを記述することになります。コレクションは要素のシーケンスとマッピングで構成されます。シーケンスとマッピングは両方とも PHP 配列に変換されます。 +単純なスカラーをあらわすためだけに YAML ファイルを使うことはめったにありません。ほとんどの場合、コレクションをあらわすことになります。コレクションはシーケンスとマッピングのどちらかの要素になります。シーケンスとマッピングは両方とも PHP 配列に変換されます。 -シーケンスにおいて、ダッシュ (`-`) の直後にスペースを入れます: +シーケンスでは、ダッシュ (`-`) の直後にスペースを入れます。 [yml] - PHP - Perl - Python -上記の YAML ファイルは次の PHP コードと同じです: +上記の YAML コードは次の PHP コードと同等です。 [php] array('PHP', 'Perl', 'Python'); -マッピングにおいて、それぞれのキーと値のペアを表すのにコロン (`:`) とスペースを使います: +マッピングでは、キーと値のペアをあらわすには、コロン (`:`) とスペースを使います。 [yml] PHP: 5.2 MySQL: 5.1 Apache: 2.2.20 -上記のコードは次の PHP コードと同じです: +上記の YAML コードは次の PHP コードと同等です。 [php] array('PHP' => 5.2, 'MySQL' => 5.1, 'Apache' => '2.2.20'); >**NOTE** ->マッピングではキーは有効な YAML スカラーになります。 +>マッピングでは、キーは有効なスカラーの値になります。 -少なくともスペースが1つ入っていれば、コロンと値のあいだのスペースの数は問いません: +少なくともスペースが1つ入っていれば、コロンと値のあいだのスペースの数は問いません。 [yml] PHP: 5.2 MySQL: 5.1 Apache: 2.2.20 -入れ子のコレクションを表すには、1つもしくは複数のスペースで字下げします: +ネストのコレクションをあらわすには、1つもしくは複数のスペースでインデントを入れます。 [yml] "symfony 1.0": @@ -162,7 +160,7 @@ YAML フォーマットは複雑な入れ子のデータ構造を記述するこ PHP: 5.2 Propel: 1.3 -上記の YAML は次の PHP コードと同じです: +上記の YAML コードは次の PHP コードと同等です。 [php] array( @@ -176,9 +174,9 @@ YAML フォーマットは複雑な入れ子のデータ構造を記述するこ ), ); -YAML ファイルのなかで字下げするときに覚えておくことが1つあります: *字下げには1つもしくは複数のスペースを使い、タブを使ってはなりません*。 +YAML コードのなかでインデントを入れるときに念頭に置くことが1つあります。*1つもしくは複数のスペースを使います。タブを使ってはなりません*。 -次のようにシーケンスとマッピングを入れ子にできます: +次のようにシーケンスとマッピングをネストにすることができます。 [yml] '第1章': @@ -188,19 +186,19 @@ YAML ファイルのなかで字下げするときに覚えておくことが1 - はじめに - ヘルパー -スコープを表すのに字下げよりも明確なインジケータが使われるので、フロースタイルはコレクションを表すのに便利です。 +スコープをあらわすのにインデントよりもわかりやすい記号が使われるので、フロースタイルはコレクションをあらわすのに適しています。 -シーケンスでは、コレクションは、角かっこ (`[]`) で囲まれカンマで区切られたリストとして表すことができます: +シーケンススタイルでは、コレクションは、角かっこ (`[]`) で囲まれ、カンマで区切られたリストとしてあらわされます。 [yml] [PHP, Perl, Python] -マッピングでは、コレクションは、波かっこ (`{}`) で囲まれ、カンマで区切られたキーもしくは値として表すことができます: +マッピングスタイルでは、コレクションは、波かっこ (`{}`) で囲まれ、カンマで区切られたキーもしくは値としてあらわされます。 [yml] { PHP: 5.2, MySQL: 5.1, Apache: 2.2.20 } -より見やすくするために、複数のスタイルを混ぜることができます: +見やすくするために、複数のスタイルを組み合わせることができます。 [yml] '第1章': [はじめに, イベントの種類] @@ -215,7 +213,7 @@ YAML ファイルのなかで字下げするときに覚えておくことが1 コメント -------- -コメントを表すには、行頭にハッシュ記号 (`#`) をつけます: +文字列の行頭をハッシュ記号 (`#`) にすればコメントになります。 [yml] # 行コメント @@ -223,12 +221,12 @@ YAML ファイルのなかで字下げするときに覚えておくことが1 "symfony 1.2": { PHP: 5.2, Propel: 1.3 } >**NOTE** ->コメントは YAML パーサーによって無視され、コレクションの入れ子の現在のレベルにしたがって字下げされます。 +>コメントは YAML パーサーによって無視され、コレクションのネストの現在のレベルにしたがってインデントが入ります。 動的な YAML ファイル -------------------- -symfony では、YAML のなかで PHP コードを記述することが可能で、YAML ファイルがパースされる直前に PHP コードが評価されます: +symfony のプロジェクトでは、YAML ファイルのなかで PHP コードを書くことが可能です。PHP コードが評価されるタイミングは YAML ファイルがパースされる直前です。 [php] 1.0: @@ -236,9 +234,9 @@ symfony では、YAML のなかで PHP コードを記述することが可能 1.1: version: "" -字下げで散らかさないようにご注意ください。YAML ファイルに PHP コードを追加するとき、次のシンプルなティップスを思い出してください: +インデントで散らかさないようにご注意ください。YAML ファイルに PHP コードを書き加えるとき、次のルールを思い出してください。 - * `` ステートメントは行で始めるもしくは値に埋め込まなければなりません。 + * `` ステートメントは行ではじめるか、値に埋め込まなければなりません。 * `` ステートメントが単一行で終わるとき、改行 (`\n`) を明示的に出力する必要があります。 @@ -247,7 +245,7 @@ symfony では、YAML のなかで PHP コードを記述することが可能 すべての例 ---------- -次の例は、このドキュメントで説明したほとんどの YAML の構文を利用しています: +次の例では、この章で述べたほとんどの YAML 構文を利用しています。 [yml] "symfony 1.0": diff --git a/reference/ja/03-Configuration-Files-Principles.markdown b/reference/ja/03-Configuration-Files-Principles.markdown index 150c17a..5da5c51 100644 --- a/reference/ja/03-Configuration-Files-Principles.markdown +++ b/reference/ja/03-Configuration-Files-Principles.markdown @@ -1,22 +1,22 @@ 設定ファイルの原則 =================== -symfony の設定ファイルは一連の共通原則にしたがって共通のプロパティを共有します。この節ではほかの節のガイダンスとして共通原則を詳しく説明します。 +symfony の設定ファイルは一連の共通原則にしたがって共通のプロパティを共有します。ほかの章のガイダンスとして、この章では共通原則をくわしく説明します。 キャッシュ ---------- -symfony のすべての設定ファイルはコンフィギュレーションハンドラクラスによって PHP ファイルとしてキャッシュされます。`is_debug` 設定が `false` にセットされているとき (たとえば `prod` 環境)、YAML ファイルは初回リクエストのときのみアクセスされます。次回以降のリクエストでは PHP キャッシュが使われます。このような仕様が意味するのは、初回時のみ YAML ファイルのパースと解釈を行うことで、「重い」処理は1回だけで済むということです。 +symfony において設定ファイルのキャッシュはすべてコンフィギュレーションハンドラクラスによって PHP ファイルとして保存されます。`is_debug` 設定に `false` がセットされている場合 (たとえば `prod` 環境)、YAML ファイルがアクセスされるのは初回リクエストのときにかぎられます。次回以降のリクエストではキャッシュとして保存された PHP ファイルが使われます。このような仕様が意味するのは、YAML ファイルのパースと解釈が実行されるのは初回リクエストにかぎられるので、「重い」処理は1回だけですむということです。 >**TIP** ->`dev` 環境のデフォルトでは、`is_debug` が `true` にセットされており、設定ファイルが変更されるたびにコンパイルが行われます (symfony がファイルの修正時刻をチェックします)。 +>`dev` 環境のデフォルトでは、`is_debug` 設定に `true` がセットされており、設定ファイルが変更されるたびにコンパイルが実行されます (symfony がファイルの修正時刻をチェックします)。 -それぞれの設定ファイルのパースとキャッシュは、[`config_handler.yml`](#chapter_14_config_handlers_yml) で設定されている特別なコンフィギュレーションハンドラクラスで行われます。 +それぞれの設定ファイルのパースとキャッシュは、[`config_handler.yml`](#chapter_14_config_handlers_yml) ファイルで指定されている特別なコンフィギュレーションハンドラクラスが担当します。 -次の節で「コンパイル」について説明します。コンパイルとは、初回アクセスのときに、YAML ファイルが PHP ファイルに変換され、キャッシュに保存されることを意味します。 +次の節で「コンパイル」について説明します。コンパイルされるとは、初回アクセスのときに、YAML ファイルが PHP ファイルに変換され、キャッシュに保存されることを意味します。 >**TIP** ->コンフィギュレーションキャッシュのリロードを強制するには、`cache:clear` タスクを使います: +>コンフィギュレーションキャッシュのリロードを強制するには、`cache:clear` タスクを実行します。 > > $ php symfony cache:clear --type=config @@ -27,47 +27,46 @@ symfony のすべての設定ファイルはコンフィギュレーションハ `core_compile.yml`、`factories.yml`、`generator.yml`、`databases.yml`、 `filters.yml`、`view.yml`、`autoload.yml` -設定ファイルのなかには、あらかじめ定義されている定数の使用を許可するものがあります。定数は `%XXX%` (XXX は大文字のキー) で表されるプレースホルダで宣言され、「コンパイル」のときに実際の値に置き換わります。 +設定ファイルのなかにはあらかじめ定義されている定数の使用を許可しているものがあります。定数の宣言は `%XXX%` プレースホルダ (XXX は大文字のキー) であらわされ、「コンパイル」のときに実際の値に置き換わります。 ### コンフィギュレーションの設定項目 -定数には `settings.yml` 設定ファイルで定義されている任意の設定が格納されます。プレースホルダのキーは `SF_` をプレフィックスとする大文字の設定キーの名前です: +`settings.yml` ファイルで定義されている任意の設定に定数を投入することができます。プレースホルダのキーは `SF_` をプレフィックスとする大文字の設定キーの名前です。 [yml] logging: %SF_LOGGING_ENABLED% -symfony が設定ファイルをコンパイルするとき、既存の `%SF_XXX%` プレースホルダはすべて `settings.yml` からの値に置き換わります。上記の例では、`SF_LOGGING_ENABLED` プレースホルダは `settings.yml` で定義されている `logging_enabled` の値に置き換わります。 +symfony が設定ファイルをコンパイルするとき、既存のすべての `%SF_XXX%` プレースホルダは `settings.yml` ファイルからの値に置き換わります。上記の例では、`SF_LOGGING_ENABLED` プレースホルダは `settings.yml` ファイルで定義されている `logging_enabled` 設定の値に置き換わります。 ### アプリケーションの設定項目 -`app.yml` 設定ファイルで定義されている設定にアクセスするには、キーの名前にプレフィックスの `APP_` をつけた文字列を使います。 +`app.yml` ファイルで定義されている設定にアクセスするには、キーの名前にプレフィックスの `APP_` をつけた文字列を使います。 ### 特別な定数 -デフォルトでは、現在のフロントコントローラに合わせて、symfony は4つの定数を定義します: +デフォルトでは、現在のフロントコントローラに対して4つの定数が定義されています。 - | 定数 | 説明 | コンフィギュレーション
メソッド | - | ---------------------- | ----------- --- | -------------------------------------- | + | 定数 | 説明 | コンフィギュレーションメソッド | + | ---------------------- | -------------- | -------------------------------------- | | ~`SF_APP`~ | 現在のアプリケーションの名前 | `getApplication()` | - | ~`SF_ENVIRONMENT`~ | 現在の環境の名前 | `getEnvironment()` | + | ~`SF_ENVIRONMENT`~ | 現在の環境の名前 | `getEnvironment()` | | ~`SF_DEBUG`~ | デバッグモードが有効であるか | `isDebug()` | | ~`SF_SYMFONY_LIB_DIR`~ | symfony ライブラリのディレクトリ | `getSymfonyLibDir()` | ### ディレクトリ -ディレクトリもしくはファイルパスを参照するとき、決め打ちよりも定数のほうがはるかに便利です。共通のプロジェクトとアプリケーションディレクトリのために、symfony は多くの定数を定義します。 +ディレクトリもしくはファイルパスを参照するとき、ハードコーディングよりも定数のほうがはるかに便利です。共通のプロジェクトとアプリケーションディレクトリのためにさまざまな定数が定義されています。 -階層の基点になる定数は `SF_ROOT_DIR` で、これはプロジェクトのルートディレクトリを表します。ほかのすべての定数はこのルートディレクトリから派生します。 +階層の基点となるプロジェクトのルートディレクトリをあらわす定数は `SF_ROOT_DIR` です。ほかのすべての定数はこのルートディレクトリから派生します。 -プロジェクトのディレクトリ構造は次のように定義されています: +プロジェクトのディレクトリ構造は次のように定義されています。 - | 定数 | デフォルト値 | + | 定数 | デフォルト | | ------------------ | -------------------- | | ~`SF_APPS_DIR`~ | `SF_ROOT_DIR/apps` | | ~`SF_CONFIG_DIR`~ | `SF_ROOT_DIR/config` | | ~`SF_CACHE_DIR`~ | `SF_ROOT_DIR/cache` | | ~`SF_DATA_DIR`~ | `SF_ROOT_DIR/data` | - | ~`SF_DOC_DIR`~ | `SF_ROOT_DIR/doc` | | ~`SF_LIB_DIR`~ | `SF_ROOT_DIR/lib` | | ~`SF_LOG_DIR`~ | `SF_ROOT_DIR/log` | | ~`SF_PLUGINS_DIR`~ | `SF_ROOT_DIR/plugins`| @@ -75,9 +74,9 @@ symfony が設定ファイルをコンパイルするとき、既存の `%SF_XXX | ~`SF_WEB_DIR`~ | `SF_ROOT_DIR/web` | | ~`SF_UPLOAD_DIR`~ | `SF_WEB_DIR/uploads` | -アプリケーションのディレクトリ構造は `SF_APPS_DIR/APP_NAME` ディレクトリの下で定義されています: +アプリケーションのディレクトリ構造は `SF_APPS_DIR/APP_NAME` ディレクトリの下で定義されています。 - | 定数 | デフォルト値 | + | 定数 | デフォルト | | ----------------------- | ---------------------- | | ~`SF_APP_CONFIG_DIR`~ | `SF_APP_DIR/config` | | ~`SF_APP_LIB_DIR`~ | `SF_APP_DIR/lib` | @@ -85,9 +84,9 @@ symfony が設定ファイルをコンパイルするとき、既存の `%SF_XXX | ~`SF_APP_TEMPLATE_DIR`~ | `SF_APP_DIR/templates` | | ~`SF_APP_I18N_DIR`~ | `SF_APP_DIR/i18n` | -最後に、アプリケーションキャッシュのディレクトリ構造は次のように定義されています: +最後に、アプリケーションキャッシュのディレクトリ構造は次のように定義されています。 - | 定数 | デフォルト値 | + | 定数 | デフォルト | | ------------------------- | -------------------------------- | | ~`SF_APP_BASE_CACHE_DIR`~ | `SF_CACHE_DIR/APP_NAME` | | ~`SF_APP_CACHE_DIR`~ | `SF_CACHE_DIR/APP_NAME/ENV_NAME` | @@ -102,7 +101,7 @@ symfony が設定ファイルをコンパイルするとき、既存の `%SF_XXX *設定ファイル*: `settings.yml`、`factories.yml`、`databases.yml`、`app.yml` -symfony の設定ファイルのなかには環境を認識するものがあり、これらの環境認識は symfony が動く現在の環境に依存します。これらの設定ファイルには環境ごとに異なるセクションが用意されており、それぞれのコンフィギュレーションを定義できます。新しいアプリケーションを作るとき、symfony は3つのデフォルト環境 (`prod`、`test` と `dev`) を含む適切な設定ファイルを用意します: +設定ファイルのなかには環境を認識するものがあり、これらの環境認識は symfony のプロジェクトがホストされているサーバーの環境にもとづいています。これらの設定ファイルには、環境ごとに専用のセクションが設けられており、環境ごとに異なるコンフィギュレーションを定義できます。作られた直後のアプリケーションでは、3つのデフォルト環境 (`prod`、`test` と `dev`) を含む設定ファイルが用意されています。 [yml] prod: @@ -117,7 +116,7 @@ symfony の設定ファイルのなかには環境を認識するものがあり all: # すべての環境のデフォルトコンフィギュレーション -symfony が設定ファイルからの値を必要とするとき、現在の環境セクションで見つかるコンフィギュレーションと `all` セクションのコンフィギュレーションをマージします。特別な `all` セクションはすべての環境のデフォルトコンフィギュレーションを定義します。環境セクションが定義されていなければ、symfony は代わりに `all` コンフィギュレーションを使います。 +symfony が設定ファイルからの値を必要とするとき、現在の環境セクションで見つかるコンフィギュレーションと `all` セクションのコンフィギュレーションがマージされます。`all` セクションは特殊なセクションで、すべての環境のデフォルトコンフィギュレーションが定義されています。環境セクションが定義されていなければ、代わりに `all` コンフィギュレーションが使われます。 コンフィギュレーションカスケード -------------------------------- @@ -126,20 +125,20 @@ symfony が設定ファイルからの値を必要とするとき、現在の環 `factories.yml`、`databases.yml`、`security.yml`、`cache.yml`、 `app.yml`、`filters.yml`、`view.yml` -プロジェクトのディレクトリ構造には複数の `config/` サブディレクトリが収められており、設定ファイルを設置すれば、考慮されます。 +symfony のプロジェクトディレクトリには複数の `config/` サブディレクトリが収められており、設定ファイルを配置することができます。 -コンフィギュレーションがコンパイルされるとき、すべての異なるファイルからの値は次の優先順位にしたがってマージされます +コンフィギュレーションがコンパイルされるとき、すべての異なるファイルからの値は次の優先順位にしたがってマージされます。 * モジュールのコンフィギュレーション (`PROJECT_ROOT_DIR/apps/APP_NAME/modules/MODULE_NAME/config/XXX.yml`) * アプリケーションのコンフィギュレーション (`PROJECT_ROOT_DIR/apps/APP_NAME/config/XXX.yml`) * プロジェクトのコンフィギュレーション (`PROJECT_ROOT_DIR/config/XXX.yml`) * プラグインで定義されているコンフィギュレーション (`PROJECT_ROOT_DIR/plugins/*/config/XXX.yml`) - * symfony ライブラリで定義されているデフォルトコンフィギュレーション (`SF_LIB_DIR/config/XXX.yml`) + * symfony のライブラリで定義されているデフォルトコンフィギュレーション (`SF_LIB_DIR/config/XXX.yml`) -たとえば、アプリケーションディレクトリのなかで定義されている `settings.yml` は、プロジェクトの `config/` ディレクトリのメインコンフィギュレーションのセット、およびフレームワーク自身に収められているデフォルトコンフィギュレーション (`lib/config/config/settings.yml`) を継承します。 +たとえば、アプリケーションディレクトリに配置されている `settings.yml` ファイルが継承するのは、プロジェクトの `config/` ディレクトリに収められている一連のメインコンフィギュレーション、およびフレームワーク自身に収められているデフォルトコンフィギュレーションです (`lib/config/config/settings.yml`)。 >**TIP** ->設定ファイルは、複数のディレクトリのなかで定義可能で、環境を認識します。次の優先順位リストが適用されます: +>設定ファイルは複数のディレクトリのなかで定義可能で、環境を認識します。次の優先順位リストが適用されます。 > > 1. モジュール > 2. アプリケーション diff --git a/reference/ja/04-Settings.markdown b/reference/ja/04-Settings.markdown index adaadf4..226d35f 100644 --- a/reference/ja/04-Settings.markdown +++ b/reference/ja/04-Settings.markdown @@ -1,16 +1,16 @@ settings.yml 設定ファイル ========================= -symfony のほとんどのコンフィギュレーションは YAML もしくはプレーンな PHP で書かれている設定ファイルを通して変更できます。このセクションでは `settings.yml` を説明します。 +symfony のコンフィギュレーションの大半は YAML もしくはプレーンな PHP で書かれた設定ファイルを通じて変更できます。この章では `settings.yml` ファイルを説明します。 -アプリケーションのメイン設定ファイルである `settings.yml` は `apps/APP_NAME/config/` ディレクトリで見つかります。 +アプリケーションの `settings.yml` ファイルは `apps/APP_NAME/config/` ディレクトリに配置されています。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`settings.yml` ファイルでは、**環境が認識され**、**コンフィギュレーションカスケードのメカニズム**がはたらきます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`settings.yml` ファイルでは、**環境**が認識され、**コンフィギュレーションカスケード**のメカニズムがはたらいています。 -それぞれの環境には2つのサブセクション (`.actions` と `.settings`) が用意されています。共通ページにおいてレンダリングされるデフォルトのアクション以外、すべてのコンフィギュレーションディレクティブは `.settings` サブセクションの下に格納されています。 +それぞれの環境には2つのサブセクション (`.actions` と `.settings`) が設けられています。共通ページにおいてレンダリングされるデフォルトのアクション以外、すべてのコンフィギュレーションディレクティブは `.settings` サブセクションにとりそろえられています。 >**NOTE** ->`settings.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfDefineEnvironmentConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`settings.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfDefineEnvironmentConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。
@@ -78,22 +78,22 @@ symfony のほとんどのコンフィギュレーションは YAML もしくは ### ~`login`~ -`login` アクションは認証されていないユーザーがセキュアなページにアクセスしようとする際に実行されます。 +`login` アクションは認証されていないユーザーが認証を必要とするページにアクセスしようとすると実行されます。 ### ~`secure`~ -`secure` アクションはユーザーが必須のクレデンシャルをもたないときに実行されます。 +`secure` アクションはアクセスしてきたユーザーが必須のクレデンシャルをもっていない場合に実行されます。 ### ~`module_disabled`~ -`module_disabled` アクションはユーザーが無効なモジュールをリクエストするときに実行されます。 +`module_disabled` アクションはユーザーが無効なモジュールをリクエストした際に実行されます。 `.settings` サブセクション -------------------------- -`.settings` サブセクションはフレームワークの設定を調整する場所です。下記のパラグラフでは、すべての利用可能な設定項目を説明し、これらを重要度順におおまかに並べてあります。 +`.settings` サブセクションではフレームワークの設定を調整します。下記の段落では、利用可能なすべての設定項目を説明します。設定項目はおおまかな重要度順で並べられています。 -`.settings` セクションで定義されている設定項目の名前はすべて設定の名前にプレフィックスの `sf_` をつけたものであり、`sfConfig` オブジェクトを通してコードのなかの任意の場所で利用できます。たとえば `charset` 設定の値を得るには、次のコードを使います: +`.settings` セクションで定義されているすべての設定項目の名前は設定の名前にプレフィックスの `sf_` をつけたものであり、`sfConfig` オブジェクトを通じて任意の場所で利用できます。たとえば `charset` 設定の値を得るには、コードを次のように書きます。 [php] sfConfig::get('sf_charset'); @@ -102,103 +102,103 @@ symfony のほとんどのコンフィギュレーションは YAML もしくは *デフォルト*: `true` -`escaping_strategy` 設定はブール値をとり、出力エスケーパサブフレームワークが有効であるかどうかを決めます。この設定が有効なとき、`escaping_method` 設定で定義されているヘルパー関数を呼び出すことで、テンプレートのなかで利用可能なすべての変数は自動的にエスケープされます (下記を参照)。 +`escaping_strategy` 設定は出力エスケーパサブフレームワークを有効にするかどうかを決めます。この設定はブール値をとります。この設定が有効な場合、`escaping_method` 設定で定義されているヘルパー関数が呼び出され、テンプレートのなかで利用可能なすべての変数は自動的にエスケープされます (下記の説明をご参照ください)。 -`escaping_method` 設定は symfony によって使われるデフォルトのヘルパーであることにご注意ください。しかし、たとえば JavaScript スクリプトのタグで変数を出力するときなど、ケースバイケースでこの設定をオーバーライドできます。 +`escaping_method` 設定がデフォルトのヘルパーであることにご注意ください。ケースバイケースでこの設定をオーバーライドすれば、たとえば JavaScript スクリプトタグのなかで変数を出力するなどの状況に対処できます。 出力エスケーパサブフレームワークはエスケープの際に `charset` 設定を使います。 -デフォルトの `true` のままにしておくことをぜひおすすめします。 +設定の値はデフォルトの `true` のままにしておくことをぜひおすすめします。 >**TIP** ->アプリケーションを `generate:app` タスクで作る際に `--escaping-strategy` オプションを指定すれば、この設定を自動的にセットできます。 +>アプリケーションを `generate:app` タスクで作る際に `--escaping-strategy` オプションを指定すれば、エスケープは自動的に有効になります。 ### ~`escaping_method`~ *デフォルト*: `ESC_SPECIALCHARS` -`escaping_method` 設定はテンプレートのなかでエスケープするために使うデフォルト関数を定義します (上記の `escaping_strategy` 設定を参照)。 +`escaping_method` 設定はテンプレートのなかでエスケープに使われるデフォルトの関数を定義します (上記の `escaping_strategy` 設定をご参照ください)。 -組み込み関数の1つ: ~`ESC_RAW`~、~`ESC_ENTITIES`~、~`ESC_JS`~、 -~`ESC_JS_NO_ENTITIES`~ と~`ESC_SPECIALCHARS`~ を選ぶ、もしくは独自関数を作ることができます。 +組み込み関数の1つを選ぶ、もしくは自前の関数を作ることができます (~`ESC_RAW`~、~`ESC_ENTITIES`~、~`ESC_JS`~、 +~`ESC_JS_NO_ENTITIES`~ と ~`ESC_SPECIALCHARS`~)。 -ほとんどの場合、デフォルトで十分です。英語もしくはヨーロッパの言語だけを扱う場合には `ESC_ENTITIES` ヘルパーを選ぶこともできます。 +ほとんどの場合、デフォルトで事足ります。英語もしくはヨーロッパの言語だけを扱う場合には `ESC_ENTITIES` ヘルパーを選ぶこともできます。 ### ~`csrf_secret`~ *デフォルト*: ランダムに生成される秘密の文字列 -`csrf_secret` 設定はアプリケーションにおいて一意性をもつ秘密の文字列です。`false` にセットされていない場合、フォームフレームワークで定義されているすべてのフォームで CSRF 防止機能が有効になります。この設定は `link_to()` ヘルパーにも使われ、リンクをフォームに変換することが必要なとき (たとえば HTTP `DELETE` メソッドをシミュレートしたい場合) に役立ちます。 +`csrf_secret` 設定はアプリケーションにおいて一意性のある秘密の文字列です。この設定に `false` がセットされていないかぎり、フォームフレームワークで定義されているすべてのフォームで CSRF 対策機能が有効になります。この設定は `link_to()` ヘルパーにも使われ、リンクをフォームに変換することが必要な場合に役立ちます (たとえば HTTP `DELETE` メソッドをシミュレートしたい場合)。 -デフォルトをあなたが選んだ一意性のある秘密の文字列に変更することをぜひおすすめします。 +デフォルトをあなたが選んだ一意性のある秘密の文字列に変更しておくことをぜひおすすめします。 >**TIP** ->アプリケーションを `generate:app` タスクで作る際に `--csrf-secret` オプションを指定すれば、この設定は自動的にセットされます +>`generate:app` タスクでアプリケーションを作る際に `--csrf-secret` オプションを指定すれば、CSRF 対策機能は自動的に有効になります。 ### ~`charset`~ *デフォルト*: `utf-8` -`charset` 設定はフレームワークのあらゆる場所で使われる文字集合を指定します。適用範囲はレスポンスの `Content-Type` ヘッダーから出力エスケーピングまで及びます。 +`charset` 設定はフレームワークのあらゆる場所に使われる文字集合を指定します。この設定の利用範囲はレスポンスの `Content-Type` ヘッダーから出力エスケーピングまでおよびます。 -ほとんどの場合、デフォルトで十分です。 +ほとんどの場合、デフォルトで事足ります。 >**WARNING** ->この設定はフレームワークの多くの場所で使われるので、この値は複数の場所で保存されます。この設定を変更した後では、開発環境であっても、コンフィギュレーションキャッシュをクリアしなければなりません。 +>この設定の値はフレームワークのさまざまな場所で使われるので、複数の場所に保存されます。この設定を変更した後では、開発環境であっても、コンフィギュレーションのキャッシュをクリアしなければなりません。 ### ~`enabled_modules`~ *デフォルト*: `[default]` -`enabled_modules` 設定はこのアプリケーションで有効なモジュール名の配列です。デフォルトでは、プラグインもしくは symfony コアで定義されているモジュールは有効ではなく、これらにアクセスできるようにするには、この配列に加えなければなりません。 +`enabled_modules` 設定はこのアプリケーションで有効なモジュール名の配列です。デフォルトでは、プラグインもしくは symfony コアで定義されているモジュールは有効ではなく、これらにアクセスできるようにするには、この配列につけ加えなければなりません。 -モジュールの追加方法はシンプルで、リストに名前を加えるだけです (モジュールの順序は問いません): +モジュールの追加方法はシンプルで、リストに名前を加えるだけです (モジュールの順序は問いません)。 [yml] enabled_modules: [default, sfGuardAuth] -`settings.yml` に用意されているサブセクションの `.actions` において、セットされているすべてのデフォルトアクションはフレームワークで定義されている `default` モジュールに収められています。これらすべてをカスタマイズし、この設定から `default` モジュールを除外することをおすすめします。 +`settings.yml` ファイルの `.actions` サブセクションであらかじめ定義されているすべてのデフォルトアクションは symfony フレームワークの `default` モジュールに収められています。これらすべてをカスタマイズし、この設定から `default` モジュールを除外しておくことをおすすめします。 ### ~`default_timezone`~ *デフォルト*: なし -`default_timezone` 設定は PHP で使われるデフォルトのタイムゾーンを定義します。この設定は PHP で認識される任意の[タイムゾーン](http://www.php.net/manual/class.datetimezone.php)をとります。 +`default_timezone` 設定は PHP が使うデフォルトのタイムゾーンを定義します。この設定は PHP が認識する任意の[タイムゾーン](http://www.php.net/manual/class.datetimezone.php)をとります。 >**NOTE** ->タイムゾーンが定義されていなければ、`php.ini` ファイルで定義することをおすすめします。そうでなければ、symfony は PHP の [`date_default_timezone_get()`](http://www.php.net/date_default_timezone_get) 関数を呼び出すことで最善のタイムゾーンを推測します。 +>タイムゾーンは `php.ini` ファイルのなかで設定しておくことをおすすめします。そうでなければ、symfony は PHP の [`date_default_timezone_get()`](http://www.php.net/date_default_timezone_get) 関数を呼び出して、最善のタイムゾーンを推測します。 ### ~`cache`~ *デフォルト*: `false` -`cache` 設定はテンプレートキャッシュを有効もしくは無効にします。 +`cache` 設定はテンプレートのキャッシュを有効もしくは無効にします。 >**TIP** ->キャッシュシステム全般のコンフィギュレーションの変更は `factories.yml` 設定ファイルの [`view_cache_manager`](#chapter_05_view_cache_manager) と [`view_cache`](#chapter_05_view_cache) セクションで行います。コンフィギュレーションのきめ細かい調整は [`cache.yml`](#chapter_09) 設定ファイルで行います。 +>キャッシュシステム全体のコンフィギュレーションを変更できる場所は `factories.yml` ファイルの [`view_cache_manager`](#chapter_05_view_cache_manager) と [`view_cache`](#chapter_05_view_cache) セクションです。コンフィギュレーションをきめ細かく調整できる場所は [`cache.yml`](#chapter_09) ファイルです。 ### ~`etag`~ *デフォルト*: `dev` と `test` 環境を除いて、デフォルトでは `true` -`etag` 設定は HTTP の `ETag` ヘッダーの自動生成を有効もしくは無効にします。symfony によって生成される ETag はレスポンスのコンテンツの単純な md5 です。 +`etag` 設定は HTTP の `ETag` ヘッダーの自動生成を有効もしくは無効にします。レスポンスのコンテンツにおいて、symfony によって生成される ETag ヘッダーは単純な md5 のハッシュです。 ### ~`i18n`~ *デフォルト*: `false` -`i18n` 設定は国際化対応サブフレームワークを有効もしくは無効にします。この設定はブール値をとります。アプリケーションを国際化対応にするのであれば、この設定を `true` にセットします。 +`i18n` 設定は国際対応サブフレームワークを有効もしくは無効にします。この設定はブール値をとります。国際対応したアプリケーションを開発するのであれば、この設定に `true` をセットします。 >**TIP** ->国際化対応システム全般のコンフィギュレーションの変更は `factories.yml` 設定ファイルの [`i18n`](#chapter_05_i18n) セクションで行います。 +>国際対応システム全般において、コンフィギュレーションを変更できる場所は `factories.yml` ファイルの [`i18n`](#chapter_05_i18n) セクションです。 ### ~`default_culture`~ *デフォルト*: `en` -`default_culture` 設定は国際化サブフレームワークで使われるデフォルトのカルチャを定義します。この設定は任意の有効なカルチャの文字列をとります。 +`default_culture` 設定は国際対応サブフレームワークで使われるデフォルトのカルチャを定義します。この設定は任意の有効なカルチャの文字列をとります。 ### ~`standard_helpers`~ @@ -208,23 +208,23 @@ symfony のほとんどのコンフィギュレーションは YAML もしくは ### ~`no_script_name`~ -*デフォルト*: 最初に作られるアプリケーションの `prod` 環境では `true`、その他すべてでは `false` +*デフォルト*: 新しいアプリケーションの `prod` 環境では `true`、それ以外の環境では `false` -`no_script_name` 設定は生成される URL にフロントコントローラスクリプトの名前をつけ足すかどうかを決めます。最初に作られるアプリケーションの `prod` 環境のデフォルトでは、この設定は `generate:app` タスクによって `true` にセットされます。 +`no_script_name` 設定は生成される URL にフロントコントローラスクリプトの名前をつけ足すかどうかを決めます。`generate:app` タスクによって作られた新しいアプリケーションの `prod` 環境において、この設定には `true` がセットされています。 -すべてのフロントコントローラが同じディレクトリ (`web/`) にある場合、この設定を `true` にセットできるのはあきらかに1つのアプリケーションと環境だけです。`no_script_name` が `true` にセットされているアプリケーションが複数必要であれば、該当するフロントコントローラを Web 公開ディレクトリのなかに移動させます。 +すべてのフロントコントローラが同じディレクトリ (`web/`) に配置されている場合、この設定に `true` をセットできるのはあきらかに1つのアプリケーションと環境にかぎられます。`no_script_name` 設定に `true` がセットされているアプリケーションが複数必要であれば、該当するフロントコントローラを Web 公開ディレクトリに移動させます。 ### ~`lazy_cache_key`~ *デフォルト*: 新しいプロジェクトでは `true`、アップグレードしたプロジェクトでは `false` -`lazy_cache_key` 設定が有効なとき、キャッシュキーの作成はアクションもしくはパーシャルがキャッシュ可能になるまで延期されます。テンプレートパーシャルの使い方しだいではパフォーマンスが大いに改善されます。 +`lazy_cache_key` 設定が有効な場合、キャッシュキーの作成はアクションもしくはパーシャルがキャッシュ可能になるまで延期されます。テンプレートパーシャルの使いかたしだいではパフォーマンスを大きく改善できます。 ### ~`file_link_format`~ *デフォルト*: なし -デバッグメッセージにおいて、`sf_file_link_format` もしくは PHP の `xdebug.file_link_format` 設定の値がセットされている場合、ファイルパスがクリック可能なリンクに変換されます。たとえば、ファイルを TextMate で開きたい場合、次の値を使います: +デバッグメッセージにおいて、`sf_file_link_format` 設定もしくは PHP の `xdebug.file_link_format` ディレクティブに値がセットされている場合、ファイルパスはクリック可能なリンクに変換されます。たとえば、ファイルが TextMate で開かれるようにしたいのであれば、次の値をセットします。 [yml] txmt://open?url=file://%f&line=%l @@ -235,16 +235,16 @@ symfony のほとんどのコンフィギュレーションは YAML もしくは *デフォルト*: `prod` 以外のすべての環境では `true` -`logging_enabled` 設定はロギングサブフレームワークを有効にします。この設定を `false` にセットすれば、ロギングメカニズムが回避され、パフォーマンスが少し向上します。 +`logging_enabled` 設定はロギングサブフレームワークを有効にします。この設定に `false` がセットされていれば、ロギングメカニズムが回避され、パフォーマンスが少し改善されます。 >**TIP** ->ロギングコンフィギュレーションのきめ細かい調整は `factories.yml` 設定ファイルで行います。 +>ロギングのコンフィギュレーションをきめ細かく調整できる場所は `factories.yml` ファイルです。 ### ~`web_debug`~ *デフォルト*: `dev` 以外のすべての環境では `false` -`web_debug` 設定はデバッグツールバーを有効にします。レスポンスの Content-Type が HTML であるときにデバッグツールバーがページに投入されます。 +`web_debug` 設定はデバッグツールバーを有効にします。レスポンスの Content-Type ヘッダーに HTML がセットされている場合、デバッグツールバーがページに投入されます。 ### ~`error_reporting`~ @@ -258,34 +258,34 @@ symfony のほとんどのコンフィギュレーションは YAML もしくは `error_reporting` 設定は PHP のエラーレポートのレベルをコントロールします (ログに書き込まれ、ブラウザに表示されます)。 >**TIP** ->[ビット演算子](http://www.php.net/language.operators.bitwise)の使い方に関する情報は PHP 公式サイトにあります。 +>[ビット演算子](http://www.php.net/language.operators.bitwise)の解説は PHP 公式マニュアルに掲載されています。 -デフォルトのコンフィギュレーションはもっとも利にかなったものであり、変更すべきではありません。 +デフォルトのコンフィギュレーションがもっとも理にかなったものであり、変更すべきではありません。 >**NOTE** ->`prod` 環境のフロントコントローラでは `debug` が無効なので、ブラウザのエラー表示は自動的に無効になります。 +>`prod` 環境のフロントコントローラでは `debug` 設定が無効になっているので、ブラウザのエラー表示は自動的に無効になります。 ### ~`compressed`~ *デフォルト*: `false` -`compressed` 設定は PHP ネイティブなレスポンス圧縮を有効にします。`true` にセットされている場合、symfony は [`ob_gzhandler`](http://www.php.net/ob_gzhandler) を `ob_start()` のコールバック関数に使います。 +`compressed` 設定は PHP ネイティブなレスポンス圧縮を有効にします。この設定に `true` がセットされている場合、[`ob_gzhandler()`](http://www.php.net/ob_gzhandler) 関数が `ob_start()` 関数のコールバックに使われます。 -この設定は `false` のままにしておいて、代わりに Web サーバーに備わっている圧縮メカニズムを利用することをおすすめします。 +この設定を `false` のままにしておいて、Web サーバーに備わっている圧縮メカニズムを利用することをおすすめします。 ### ~`use_database`~ *デフォルト*: `true` -`use_database` はアプリケーションがデータベースを使うかどうかを決めます。 +`use_database` 設定はアプリケーションでデータベースを使うかどうかを決めます。 ### ~`check_lock`~ *デフォルト*: `false` -`check_lock` 設定は `cache:clear` と `project:disable` のようなタスクによって実行されるアプリケーションのロックシステムを有効もしくは無効にします。 +`check_lock` 設定は `cache:clear` や `project:disable` タスクなどによって実行されるアプリケーションのロックシステムを有効もしくは無効にします。 -`true` にセットされている場合、無効なアプリケーションへのすべてのリクエストは自動的に symfony コアの `lib/exception/data/unavailable.php` ページにリダイレクトされます。 +この設定に `true` がセットされている場合、無効なアプリケーションへのリクエストはすべて自動的に symfony コアの `lib/exception/data/` ディレクトリに配置されている `unavailable.php` ページにリダイレクトされます。 >**TIP** >`config/unavailable.php` ファイルをプロジェクトもしくはアプリケーションに追加すれば、アプリケーションが無効なときに表示されるページのデフォルトテンプレートをオーバーライドできます。 @@ -294,4 +294,4 @@ symfony のほとんどのコンフィギュレーションは YAML もしくは *デフォルト*: `/sf/sf_web_debug` -`web_debug_web_dir` はデバッグツールバーのアセット (画像、スタイルシートそして JavaScript ファイル) への Web サイト上のパスをセットします。 +`web_debug_web_dir` 設定には Web サイトにおけるデバッグツールバーのアセット (画像、スタイルシートそして JavaScript ファイル) へのパスがセットされます。 diff --git a/reference/ja/05-Factories.markdown b/reference/ja/05-Factories.markdown index 57aeda0..97ae7c7 100644 --- a/reference/ja/05-Factories.markdown +++ b/reference/ja/05-Factories.markdown @@ -1,17 +1,17 @@ factories.yml 設定ファイル ========================== -ファクトリはリクエストが存在しているあいだにフレームワークが必要とするコアオブジェクトです。これらのコンフィギュレーションは `factories.yml` 設定ファイルで変更され、`sfContext` オブジェクトを通してつねにアクセスできます: +ファクトリはリクエストが存続しているあいだに symfony フレームワークによって必要とされるコアオブジェクトです。これらのコンフィギュレーションは `factories.yml` ファイルのなかで変更することが可能で、`sfContext` オブジェクトを通じてつねにアクセスできます。 [php] - // ユーザーファクトリを取得する + // ユーザーファクトリを取得します sfContext::getInstance()->getUser(); -アプリケーションのメイン設定ファイルである `factories.yml` は `apps/APP_NAME/config/` ディレクトリで見つかります。 +アプリケーションの `factories.yml` ファイルは `apps/APP_NAME/config/` ディレクトリに配置されています。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`factories.yml` ファイルでは、**環境が認識され**、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`factories.yml` ファイルでは、**環境**が認識され、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 -`factories.yml` 設定ファイルには、名前つきファクトリのリストが用意されています: +`factories.yml` ファイルには、名前つきファクトリのリストが用意されています。 [yml] FACTORY_1: @@ -22,20 +22,21 @@ factories.yml 設定ファイル # ... -サポートされているファクトリの名前は次のとおりです: +サポートされているファクトリは次のとおりです。 + `controller`、`logger`、`i18n`、`request`、`response`、`routing`、`storage`、 `user`、`view_cache` と `view_cache_manager` -`sfContext` がファクトリを初期化するとき、ファクトリオブジェクトを設定するために使うファクトリのクラス名 (`class`) とパラメータ (`param`) を得るために、`sfContext` は `factories.yml` ファイルを読み込みます: +`sfContext` オブジェクトはファクトリを初期化するとき、`factories.yml` ファイルを読み込み、ファクトリオブジェクトを設定するために使うファクトリのクラス名 (`class`) とパラメータ (`param`) の値を得ます。 [yml] FACTORY_NAME: class: CLASS_NAME param: { ARRAY OF PARAMETERS } -ファクトリをカスタマイズできることが意味するのは、symfony コアのデフォルトクラスの代わりにカスタムクラスを使うことができるということです。これらのクラスに渡すパラメータをカスタマイズすることで、これらのクラスのデフォルトのふるまいを変更することもできます。 +ファクトリをカスタマイズできることが意味するのは、symfony コアから提供されているデフォルトのクラスの代わりに自前のクラスに切り替えられるということです。これらのクラスに渡すパラメータを調整すれば、これらのクラスのデフォルトのふるまいが変わります。 -ファクトリクラスがオートロードされないとき、`file` パスが定義され、ファクトリが作られる前に自動的にインクルードされます: +ファクトリクラスがオートロードされていなければ、`file` パスが定義され、ファクトリが作られる前に自動的にインクルードされます。 [yml] FACTORY_NAME: @@ -43,7 +44,7 @@ factories.yml 設定ファイル file: ABSOLUTE_PATH_TO_FILE >**NOTE** ->`factories.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfFactoryConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`factories.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfFactoryConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。
@@ -168,11 +169,11 @@ factories.yml 設定ファイル ### ~`charset`~ -`charset` オプションはメールメッセージに使う文字集合を定義します。デフォルトでは、`settings.yml` の `charset` 設定が使われます。 +`charset` オプションはメールメッセージに使われる文字集合を定義します。デフォルトでは、`settings.yml` ファイルの `charset` 設定が使われます。 ### ~`delivery_strategy`~ -`delivery_strategy` オプションはメーラーによってメールメッセージがどのように配信されるのかを定義します。デフォルトでは、4つの戦略を選ぶことが可能で、すべての共通ニーズに適しています: +`delivery_strategy` オプションはメーラーによるメールメッセージの配信方法を定義します。デフォルトでは、4つのストラテジを選ぶことが可能で、すべての共通ニーズに適しています。 * `realtime`: メッセージはリアルタイムで送信されます。 @@ -184,11 +185,11 @@ factories.yml 設定ファイル ### ~`delivery_address`~ -`delivery_address` オプションは、`delivery_strategy` が `single_address` にセットされているときにすべてのメッセージの受信アドレスを定義します。 +`delivery_address` オプションは `delivery_strategy` オプションに `single_address` がセットされている場合にすべてのメッセージの受信アドレスを定義します。 ### ~`spool_class`~ -`spool_class` オプションは、`delivery_strategy` が `spool` にセットされているときに使われるスプールクラスを定義します: +`spool_class` オプションは `delivery_strategy` オプションに `spool` がセットされている場合に使われるスプールクラスを定義します。 * ~`Swift_FileSpool`~: メッセージはファイルシステムに保存されます。 @@ -197,11 +198,11 @@ factories.yml 設定ファイル * ~`Swift_PropelSpool`~: メッセージは Propel モデルに保存されます。 >**NOTE** ->スプールがインスタンス化されるとき、~`spool_arguments`~ オプションはコンストラクタの引数に使われます。 +>スプールのインスタンスが作られるとき、コンストラクタの引数に ~`spool_arguments`~ オプションが渡されます。 ### ~`spool_arguments`~ -`spool_arguments` オプションはスプールのコンストラクタの引数を定義します。組み込みのキュークラスで利用できるオプションは次のとおりです: +`spool_arguments` オプションはスプールのコンストラクタの引数を定義します。組み込みのキュークラスで利用できるオプションは次のとおりです。 * `Swift_FileSpool`: @@ -209,24 +210,24 @@ factories.yml 設定ファイル * `Swift_DoctrineSpool`: - * メッセージを保存する Doctrine モデル (デフォルトは `MailMessage`) + * メッセージの保存に使われる Doctrine モデル (デフォルトは `MailMessage`) - * メッセージ保存に使われるカラムの名前 (デフォルトは `message`) + * メッセージの保存に使われるカラムの名前 (デフォルトは `message`) - * 送信するメッセージを読み出すために呼び出すメソッド (オプション)。このメソッドはキューオプションを引数にとります。 + * 送信するメッセージをとり出すために呼び出すメソッド (オプション)。このメソッドはキューオプションを引数にとります。 * `Swift_PropelSpool`: - * メッセージを保存するために使う Propel モデル (デフォルトは `MailMessage`) + * メッセージの保存に使われる Propel モデル (デフォルトは `MailMessage`) - * メッセージ保存に使うカラムの名前 (デフォルトは `message`) + * メッセージの保存に使われるカラムの名前 (デフォルトは `message`) - * 送信するメッセージを読み出すために呼び出すメソッド (オプション)。このメソッドは現在の Criteria を引数にとります。 + * 送信するメッセージをとり出すために呼び出すメソッド (オプション)。このメソッドは現在の Criteria を引数にとります。 -Doctrine スプールのコンフィギュレーションの典型例は次のとおりです: +次のコードは Doctrine スプールにおけるコンフィギュレーションの典型的な例です。 [yml] - # factories.yml のコンフィギュレーション + # factories.yml ファイルのコンフィギュレーション mailer: class: sfMailer param: @@ -236,17 +237,17 @@ Doctrine スプールのコンフィギュレーションの典型例は次の ### ~`transport`~ -`transport` オプションはメールメッセージを実際に送信するために使うトランスポートを定義します。 +`transport` オプションはメールメッセージを実際に送信するために使われるトランスポートを定義します。 -`class` 設定は `Swift_Transport` を実装する任意のクラスになります。デフォルトでは、3つの設定が提供されます: +`class` 設定は `Swift_Transport` を実装する任意のクラスになります。デフォルトでは、3つの設定が用意されています。 - * ~`Swift_SmtpTransport`~: メッセージの送信に SMTP サーバーを使います。 + * ~`Swift_SmtpTransport`~: メッセージの送信に SMTP サーバーが使われます。 - * ~`Swift_SendmailTransport`~: メッセージの送信に `sendmail` を使います。 + * ~`Swift_SendmailTransport`~: メッセージの送信に `sendmail` が使われます。 - * ~`Swift_MailTransport`~: メッセージの送信に PHP ネイティブの `mail()` 関数を使います。 + * ~`Swift_MailTransport`~: メッセージの送信に PHP ネイティブの `mail()` 関数が使われます。 -`param` 設定をセットすることでトランスポートを細かく調整できます。組み込みのトランスポートクラスと異なるパラメータについて知る必要のある情報は Swift Mailer の公式ドキュメントの [「Transport Types」](http://swiftmailer.org/docs/transport-types) の節で網羅されています。 +`param` 設定を変更することで、トランスポートを細かく調整できます。組み込みのトランスポートクラスと各種パラメータについては、SwiftMailer の公式ドキュメントの [「Transport Types (トランスポートの種類)」](http://swiftmailer.org/docs/transport-types) の節で網羅されています。 `request` --------- @@ -274,17 +275,17 @@ Doctrine スプールのコンフィギュレーションの典型例は次の ### ~`path_info_array`~ -`path_info_array` オプションは情報検索に使われるグローバルな PHP 配列を定義します。コンフィギュレーションしだいではデフォルトの `SERVER` から `ENV` に変更するとよいでしょう。 +`path_info_array` オプションは情報検索に使われるグローバルな PHP 配列を定義します。コンフィギュレーションによってはデフォルトの `SERVER` から `ENV` に変更するとよいでしょう。 ### ~`path_info_key`~ -`path_info_key` オプションは `PATH_INFO` の情報を見つけられるキーを定義します。 +`path_info_key` オプションは `PATH_INFO` の情報を見つけられるようにするためのキーを定義します。 -`IIFR` もしくは `ISAPI` のような rewrite モジュールが付属する IIS を使う場合、このオプションの値を `HTTP_X_REWRITE_URL` に変更するとよいでしょう。 +`IIFR` もしくは `ISAPI` のような rewrite モジュールが付属している IIS を使うのであれば、このオプションの値を `HTTP_X_REWRITE_URL` に変更するとよいでしょう。 ### ~`formats`~ -`formats` オプションはファイルの拡張子と `Content-Type` の配列です。このオプションはリクエスト URI の拡張子に合わせてレスポンスの `Content-Type` を自動管理するのに使われます。 +`formats` オプションはファイルの拡張子と `Content-Type` の配列です。このオプションはリクエスト URI の拡張子に応じてレスポンスヘッダーの `Content-Type` を調整するのに使われます。 ### ~`relative_url_root`~ @@ -315,15 +316,15 @@ Doctrine スプールのコンフィギュレーションの典型例は次の ### ~`send_http_headers`~ -`send_http_headers` オプションは、レスポンスのコンテンツに加えて HTTP レスポンスヘッダーを送信するかどうかを指定します。ヘッダーを実際に送信するのは PHP の `header()` 関数です。この関数が出力の後でヘッダーを送信しようとすると警告を発してくれるので、このオプションはテストの際に重宝します。 +`send_http_headers` オプションは、レスポンスのコンテンツに加えて HTTP レスポンスヘッダーを送信するかどうかを決めます。ヘッダーを実際に送信するのは PHP の `header()` 関数です。出力の後でヘッダーを送信しようとすると、この関数が警告を発してくれるので、このオプションはテストの際に重宝します。 ### ~`charset`~ -`charset` オプションはレスポンスに使う文字集合を定義します。デフォルトでは、`settings.yml` の `charset` 設定が使われます。ほとんどの場合、デフォルトで十分です。 +`charset` オプションはレスポンスに使われる文字集合を定義します。デフォルトでは、`settings.yml` ファイルの `charset` 設定が使われます。ほとんどの場合、デフォルトの値で事足ります。 ### ~`http_protocol`~ -`http_protocol` オプションはレスポンスに使う HTTP プロトコルのバージョンを定義します。デフォルトでは、利用可能であれば、`$_SERVER['SERVER_PROTOCOL']` の値もしくは `HTTP/1.0` です。 +`http_protocol` オプションはレスポンスに使われる HTTP プロトコルのバージョンを定義します。デフォルトでは、利用可能であればスーパーグローバルの `$_SERVER['SERVER_PROTOCOL']` の値が使われ、それ以外の場合は `HTTP/1.0` が使われます。 `user` ------ @@ -342,16 +343,16 @@ Doctrine スプールのコンフィギュレーションの典型例は次の default_culture: %SF_DEFAULT_CULTURE% >**NOTE** ->デフォルトでは、`myUser` クラスは `sfBasicSecurityUser` を継承します。このクラスは [`security.yml`](#chapter_08) 設定ファイルで変更できます。 +>デフォルトでは、`myUser` クラスは `sfBasicSecurityUser` 基底クラスを継承します。この基底クラスは [`security.yml`](#chapter_08) ファイルのなかで変更できます。 ### ~`timeout`~ -`timeout` オプションはユーザー認証のタイムアウトを定義します。このオプションはセッションのタイムアウトとは関係ありません。デフォルトでは、30分間何もしていないユーザーの認証が自動的に解除されます。 +`timeout` オプションはユーザー認証のタイムアウトを定義します。このオプションはセッションのタイムアウトとは関係ありません。デフォルトでは、30分間何もしていないユーザーの認証は自動的に解除されます。 -このオプションを使えるのは `sfBasicSecurityUser` 基底クラスを継承するユーザークラスだけです。具体例として `myUser`生成クラスが当てはまります。 +このオプションを利用できるクラスは `sfBasicSecurityUser` 基底クラスを継承するユーザークラスにかぎられます。`myUser`生成クラスを具体例にあげることができます。 >**NOTE** ->予期しないふるまいを避けるために、セッションガベージコレクタの最長有効期間 (`session.gc_maxlifetime`) がタイムアウトよりもはるかに長くなるように、ユーザークラスによって強制されます。 +>予期せぬふるまいに遭遇しなくてすむように、ユーザークラスはセッションガベージコレクタの最長有効期間 (`session.gc_maxlifetime`) をタイムアウトよりもはるかに長く設けます。 ### ~`use_flash`~ @@ -359,15 +360,15 @@ Doctrine スプールのコンフィギュレーションの典型例は次の ### ~`default_culture`~ -`default_culture` オプションはサイトに初めて訪問したユーザーのためにデフォルトカルチャを定義します。デフォルトでは、`settings.yml` の `default_culture` が使われ、ほとんどの場合これで十分です。 +`default_culture` オプションはサイトにはじめて訪問したユーザーのデフォルトカルチャを定義します。デフォルトでは、`settings.yml` ファイルの `default_culture` 設定が使われ、たいていの場合、この値で事足ります。 >**CAUTION** ->`factories.yml` もしくは `settings.yml` の ~`default_culture`~ 設定を変更した場合、結果を確認するためにブラウザの Cookie を消去する必要があります。 +>`factories.yml` もしくは `settings.yml` ファイルの ~`default_culture`~ 設定を変更して結果を確認するには、ブラウザの Cookie を消去する必要があります。 `storage` --------- -HTTP リクエストにおけるユーザーデータの一貫性を保つために、ストレージファクトリはユーザーファクトリによって使われます。 +HTTP リクエストにおけるユーザーデータの一貫性を保つために、ユーザーファクトリはストレージファクトリを使います。 *sfContext アクセサ*: `$context->getStorage()` @@ -389,36 +390,37 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため ### ~`auto_start`~ -`auto_start` オプションは (`session_start()` 関数を通して) PHP のセッション自動開始機能を有効もしくは無効にします。 +`auto_start` オプションは (`session_start()` 関数を通じて) PHP セッションの自動開始を有効もしくは無効にします。 ### ~`session_name`~ -`session_name` オプションはユーザーセッションを保存するために symfony によって使われる Cookie の名前を定義します。デフォルトの名前は `symfony` で、このことが意味するのは、すべてのアプリケーションが同じ Cookie (と対応する認証と承認) を共有するということです。 +`session_name` オプションはユーザーセッションの保存に使われる Cookie の名前を定義します。デフォルトの名前は `symfony` で、このことが意味するのは、すべてのアプリケーションが同じ Cookie (と対応する認証と承認) を共有するということです。 ### `session_set_cookie_params()` パラメータ -`storage` ファクトリは [`session_set_cookie_params()`](http://www.php.net/session_set_cookie_params) 関数に次のオプションの値を渡します: +`storage` ファクトリは [`session_set_cookie_params()`](http://www.php.net/session_set_cookie_params) 関数に次のオプションの値を渡します。 * ~`session_cookie_lifetime`~: セッション Cookie の有効期間。秒単位で定義されます。 * ~`session_cookie_path`~: Cookie が機能するドメインのパスです。ドメインのパスに単独のスラッシュ (`/`) が使われます。 * ~`session_cookie_domain`~: Cookie のドメインで、たとえば `www.php.net` です。すべてのサブドメインで Cookie が見えるようにするには、`.php.net` のようにドメインのプレフィックスとしてドットをつけなければなりません。 - * ~`session_cookie_secure`~: `true` にセットされている場合、Cookie はセキュアなコネクションを通してのみ送信されます。 - * ~`session_cookie_httponly`~: `true` にセットされている場合、セッション Cookie を設定する際に、PHP は `httponly` フラグを送信しようとします。 + * ~`session_cookie_secure`~: このオプションに `true` がセットされている場合、Cookie はセキュアなコネクションを通じてのみ送信されます。 + * ~`session_cookie_httponly`~: このオプションに `true` がセットされている場合、セッション Cookie を設定する際に、PHP は `httponly` フラグを送信しようとします。 >**NOTE** ->それぞれのオプションの説明は PHP 公式マニュアルの `session_set_cookie_params()` 関数のページにあります。 +>PHP 公式マニュアルにおいて、それぞれのオプションの説明が `session_set_cookie_params()` 関数のページに記載されています。 ### ~`session_cache_limiter`~ -`session_cache_limiter` オプションがセットされている場合、PHP の [`session_cache_limiter()`](http://www.php.net/session_cache_limiter) 関数が呼び出され、オプションの値は引数に渡されます。 +`session_cache_limiter` オプションは `null` にセットされている場合 (デフォルト)、このオプションの値は `php.ini` ファイルにしたがって PHP によって自動的にセットされます。ほかのすべての値に関して、PHP の +[`session_cache_limiter()`](http://www.php.net/session_cache_limiter) 関数が呼び出され、オプションの値は引数として渡されます。 ### データベースストレージ固有のオプション -`sfDatabaseSessionStorage` クラスを継承するストレージを使うとき、いくつかの追加オプションが利用できます: +`sfDatabaseSessionStorage` クラスを継承するストレージを使う場合には、次の追加オプションを選べます。 * ~`database`~: データベースの名前 (必須) * ~`db_table`~: テーブルの名前 (必須) - * ~`db_id_col`~: 主キーのカラムの名前 (デフォルトは `sess_id`) + * ~`db_id_col`~: プライマリキーのカラムの名前 (デフォルトは `sess_id`) * ~`db_data_col`~: データカラムの名前 (デフォルトは `sess_data`) * ~`db_time_col`~: 時間カラムの名前 (デフォルトは `sess_time`) @@ -437,17 +439,17 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため cache_key_use_host_name: true >**CAUTION** ->[`cache`](#chapter_04_sub_cache) 設定が `true` にセットされている場合にのみこのファクトリが作られます。 +>[`cache`](#chapter_04_sub_cache) 設定に `true` がセットされている場合にかぎり、このファクトリは作られます。 -このファクトリのコンフィギュレーションの大半は `view_cache` ファクトリを通して変更されます。`view_cache` ファクトリはビューキャッシュマネージャによって使われる内部のキャッシュオブジェクトを定義します。 +このファクトリのコンフィギュレーションの大半は `view_cache` ファクトリを通じて変更されます。`view_cache` ファクトリはビューキャッシュマネージャによって使われる内部のキャッシュオブジェクトを定義します。 ### ~`cache_key_use_vary_headers`~ -`cache_key_use_vary_headers` オプションはキャッシュキーに Vary ヘッダーの部分が含まれるかどうかを指定します。実際には、`vary` キャッシュパラメータで指定されるように、このオプションの使い道はページキャッシュが HTTP ヘッダーに依存するかどうかを伝えることです (デフォルト: `true`)。 +`cache_key_use_vary_headers` オプションは Vary ヘッダーの部分をキャッシュキーに入れるどうかを指定します。`vary` キャッシュパラメータで指定されるように、このオプションの実例はページキャッシュが HTTP ヘッダーに依存するかどうかを伝えることです (デフォルト: `true`)。 ### ~`cache_key_use_host_name`~ -`cache_key_use_host_name` オプションはキャッシュキーにホスト名の部分が含まれるかどうかを指定します。このオプションの実際の使い道は、ページキャッシュがホスト名に依存するかどうかを伝えることです (デフォルト: `true`)。 +`cache_key_use_host_name` オプションはキャッシュキーにホスト名の部分が含まれるかどうかを指定します。このオプションの実例は、ページキャッシュがホスト名に依存するかどうかを伝えることです (デフォルト: `true`)。 `view_cache` ------------ @@ -466,9 +468,9 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため prefix: %SF_APP_DIR%/template >**CAUTION** ->[`cache`](#chapter_04_sub_cache) 設定が `true` にセットされている場合のみこのファクトリが定義されます。 +>[`cache`](#chapter_04_sub_cache) 設定に `true` がセットされている場合にかぎり、このファクトリは定義されます。 -`view_cache` ファクトリは `sfCache` を継承するキャッシュクラスを定義します (詳しい情報はキャッシュの節を参照)。 +`view_cache` ファクトリは `sfCache` 抽象クラスを継承するキャッシュクラスを定義しなければなりません (くわしい説明はキャッシュの節をご参照ください)。 `i18n` ------ @@ -494,7 +496,7 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため prefix: %SF_APP_DIR%/i18n >**CAUTION** ->[`i18n`](#chapter_04_sub_i18n) 設定が `true` にセットされている場合のみこのファクトリが定義されます。 +>[`i18n`](#chapter_04_sub_i18n) 設定に `true` がセットされている場合にかぎり、このファクトリは定義されます。 ### ~`source`~ @@ -504,19 +506,19 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため ### ~`debug`~ -`debug` オプションはデバッグモードをセットします。`true` にセットされている場合、未翻訳のメッセージはプレフィックスとサフィックスによって飾りつけられます (下記を参照)。 +`debug` オプションはデバッグモードを指定します。このオプションに `true` がセットされている場合、翻訳されていないメッセージはプレフィックスとサフィックスによって飾りつけられます (くわしい説明は下記の節をご参照ください)。 ### ~`untranslated_prefix`~ -`untranslated_prefix` は未翻訳のメッセージに使われるプレフィックスを定義します。 +`untranslated_prefix` オプションは翻訳されていないメッセージに使われるプレフィックスを定義します。 ### ~`untranslated_suffix`~ -`untranslated_suffix` は未翻訳のメッセージに使われるサフィックスを定義します。 +`untranslated_suffix` オプションは翻訳されていないメッセージに使われるサフィックスを定義します。 ### ~`cache`~ -`cache` オプションは国際化対応データのキャッシュに使われる匿名キャッシュファクトリを定義します (詳しい情報はキャッシュの節を参照)。 +`cache` オプションは国際対応したデータのキャッシュに使われる匿名キャッシュファクトリを定義します (くわしい説明はキャッシュの節をご参照ください)。 `routing` --------- @@ -543,57 +545,57 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため *デフォルト*: `:` -`variable_prefixes` オプションは、ルートパターンにおける変数のプレフィックスのリストを定義します。 +`variable_prefixes` オプションはルートパターンの変数につけられるプレフィックスのリストを定義します。 ### ~`segment_separators`~ *デフォルト*: `/` と `.` -`segment_separators` オプションはルートの区切り文字のリストを定義します。特定のルート以外、ルーティング全体でこのオプションをオーバーライドすることはほとんどないでしょう。 +`segment_separators` オプションはルートに使われる区切り文字のリストを定義します。特定のルートを除いて、ルーティング全体でこのオプションをオーバーライドする事態に遭遇することはまずないでしょう。 ### ~`generate_shortest_url`~ *デフォルト*: 新しいプロジェクトでは `true`、アップグレードしたプロジェクトでは `false` -`true` にセットされている場合、`generate_shortest_url` オプションはルーティングシステムに実現可能な最短ルートを生成するよう指示します。symfony 1.0 と 1.1 と後方互換性のあるルートがほしければ、`false` にセットします。 +`generate_shortest_url` オプションに `true` がセットされている場合、ルーティングシステムは実現可能な最短ルートを生成します。symfony 1.0 と 1.1 と後方互換性のあるルートが必要であれば、このオプションに `false` をセットします。 ### ~`extra_parameters_as_query_string`~ *デフォルト*: 新しいプロジェクトでは `true`、アップグレードしたプロジェクトでは `false` -ルート生成に使われていないパラメータがあるとき、`extra_parameters_as_query_string` はルート生成に使われていないパラメータをクエリ文字列に変換します。symfony 1.0 もしくは 1.1 のふるまいに戻すのであれば、`false` にセットします。これらのバージョンでは、ルート生成に使われていないパラメータはルーティングシステムによって無視されるだけでした。 +`extra_parameters_as_query_string` オプションに `true` がセットされていれば、ルート生成に使われていないパラメータはクエリ文字列に変換されます。symfony 1.0 もしくは1.1のふるまいに戻すのであれば、このオプションに `false` をセットします。これらのバージョンでは、ルート生成に使われていないパラメータはルーティングシステムによって無視されるだけでした。 ### ~`cache`~ *デフォルト*: なし -`cache` オプションはルーティングコンフィギュレーションとデータのキャッシュに使われる匿名キャッシュファクトリを定義します (詳しい情報はキャッシュの節を参照)。 +`cache` オプションはルーティングコンフィギュレーションとデータのキャッシュに使われる匿名キャッシュファクトリを定義します (くわしい説明はキャッシュの節をご参照ください)。 ### ~`suffix`~ *デフォルト*: なし -すべてのルートに使われるデフォルトのサフィックスです。このオプションは推奨されないので、もはや役に立ちません。 +すべてのルートに使われるデフォルトのサフィックスです。このオプションは推奨されていません。 ### ~`load_configuration`~ *デフォルト*: `true` -`load_configuration` オプションは `routing.yml` ファイルをオートロードの対象にして、パースする必要があるかどうかを決めます。symfony プロジェクト外部の symfony ルーティングシステムを使いたければ、`false` にセットします。 +`load_configuration` オプションは `routing.yml` ファイルをオートロードの対象に加えて、パースするかどうかを決めます。symfony プロジェクト外部の symfony ルーティングシステムを利用したいのであれば、このオプションに `false` をセットします。 ### ~`lazy_routes_deserialize`~ *デフォルト*: `false` -`true` にセットされている場合、`lazy_routes_deserialize` 設定はルーティングキャッシュの遅延デシリアライゼーションを有効にします。たくさんのルートをかかえており、マッチするルートが最初のほうにある場合、この設定はアプリケーションのパフォーマンスを改善できます。特定の状況では、パフォーマンスにわるい影響を与える可能性があるので、運用サーバーにデプロイする前に、この設定をテストすることをぜひおすすめします。 +`lazy_routes_deserialize` 設定に `true` がセットされていれば、ルーティングキャッシュの遅延デシリアライゼーションが有効になります。たくさんのルートをかかえており、もっともマッチするルートの順番が最初のほうにあれば、アプリケーションのパフォーマンスは改善されます。状況によっては、パフォーマンスにわるい影響を及ぼす可能性があるので、運用サーバーにデプロイする前に、この設定をテストしておくことをぜひおすすめします。 ### ~`lookup_cache_dedicated_keys`~ *デフォルト*: `false` -`lookup_cache_dedicated_keys` 設定はルーティングキャッシュを構築する方法を決めます。`false` にセットされている場合、キャッシュは1つの大きな値として保存されます。`true` にセットされている場合、それぞれのルートに専用のキャッシュストアクラスが用意されます。この設定はパフォーマンスを最適化します。 +`lookup_cache_dedicated_keys` 設定は生成されるルーティングキャッシュの形式を決めます。この設定に `false` がセットされている場合、キャッシュは1つの大きな値として保存されます。この設定に `true` がセットされている場合、キャッシュを保存するためにルートごとに専用のクラスが用意されます。この設定はパフォーマンスを最適化します。 -経験則によれば、ファイルベースのキャッシュクラス (たとえば `sfFileCache`) を使う場合には、この設定を `false` に、メモリベースのキャッシュクラス (たとえば `sfAPCCache`) を使う場合には、`true` にするとよいです。 +経験則によれば、ファイルベースのキャッシュクラス (たとえば `sfFileCache`) を使う場合には、この設定に `false` を、メモリベースのキャッシュクラス (たとえば `sfAPCCache`) を使う場合には、この設定に `true` をセットするとよいでしょう。 `logger` -------- @@ -630,10 +632,10 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため level: err loggers: ~ -`sfAggregateLogger` を使いたくなければ、`loggers` パラメータに `null` を指定することをお忘れなく。 +`sfAggregateLogger` クラスを使いたくなければ、`loggers` パラメータに `null` をセットしておくことをお忘れなく。 >**CAUTION** ->このファクトリはつねに定義されていますが、ロギングが実行されるのは `logging_enabled` 設定が `true` にセットされている場合のみです。 +>このファクトリはつねに定義されていますが、ロギングが実行されるのは `logging_enabled` 設定に `true` がセットされている場合にかぎられます。 ### ~`level`~ @@ -662,9 +664,9 @@ HTTP リクエストにおけるユーザーデータの一貫性を保つため 匿名キャッシュファクトリ ------------------------- -コンフィギュレーションのなかでキャッシュオブジェクトが定義されていれば、いくつかのファクトリ (`view_cache`、`i18n` と `routing`) はこのファクトリを利用できます。キャッシュオブジェクトのコンフィギュレーションはすべてのファクトリと似ています。`cache` キーは匿名キャッシュファクトリを定義します。ほかのファクトリと同じように、このファクトリには `class` と `param` エントリが用意されています。`param` エントリは任意のキャッシュクラスで利用可能な任意のオプションをとります。 +コンフィギュレーションのなかでキャッシュオブジェクトが定義されていれば、いくつかのファクトリ (`view_cache`、`i18n` と `routing`) はこのファクトリを利用できます。キャッシュオブジェクトのコンフィギュレーションはすべてのファクトリと似ています。`cache` キーは匿名キャッシュファクトリを定義します。ほかのファクトリと同じように、このファクトリには `class` と `param` エントリが用意されています。`param` エントリはキャッシュクラスで利用可能な任意のオプションをとります。 -もっとも重要なのは `prefix` オプションで、異なる環境/アプリケーション/プロジェクトのあいだでキャッシュを共有するもしくは分離することができます。 +もっとも重要なのは `prefix` オプションで、このオプションを使うことで異なる環境/アプリケーション/プロジェクトのあいだでキャッシュを共有するもしくは分離することができます。 *組み込みのキャッシュクラス*: `sfAPCCache`、`sfEAcceleratorCache`、`sfFileCache`、`sfMemcacheCache`、 diff --git a/reference/ja/06-Admin-Generator.markdown b/reference/ja/06-Admin-Generator.markdown index f696e85..0a5bbeb 100644 --- a/reference/ja/06-Admin-Generator.markdown +++ b/reference/ja/06-Admin-Generator.markdown @@ -1,24 +1,24 @@ generator.yml 設定ファイル ========================== -symfony のアドミンジェネレータによってモデルクラスのバックエンドインターフェイスを作ることができます。Propel もしくは Doctrine が ORM として使われます。 +モデルクラスのバックエンドインターフェイスの作成には symfony のアドミンジェネレータを使います。ORM として Propel もしくは Doctrine が使われます。 ### 作成 -アドミンジェネレータモジュールは `propel:generate-admin` もしくは `doctrine:generate-admin` タスクによって生成されます: +アドミンジェネレータモジュールを生成するには `propel:generate-admin` もしくは `doctrine:generate-admin` タスクを使います。 $ php symfony propel:generate-admin backend Article $ php symfony doctrine:generate-admin backend Article -上記の例では、`Article` モデルクラスに対応する `article` アドミンジェネレータモジュールが生成されます。 +上記の例では、`Article` モデルクラスに対応した `article` アドミンジェネレータモジュールが生成されます。 >**NOTE** ->`generator.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfGeneratorConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`generator.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfGeneratorConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 ### 設定ファイル -モジュールのコンフィギュレーションの変更は `apps/backend/modules/model/article/generator.yml` ファイルで行います: +モジュールのコンフィギュレーションを変更できる場所は `apps/backend/modules/model/article/` ディレクトリに配置されている `generator.yml` ファイルです。 [yml] generator: @@ -26,21 +26,21 @@ symfony のアドミンジェネレータによってモデルクラスのバッ param: # パラメータの配列 -このファイルには2つのメインエントリ: `class` と `param` が用意されています。`class` エントリに指定されているのは、Propel では `sfPropelGenerator` で、Doctrine では `sfDoctrineGenerator` です。 +このファイルには2つのメインエントリ (`class` と `param`) が用意されています。`class` エントリにセットされているデフォルトの値は、Propel の場合は `sfPropelGenerator` で、Doctrine の場合は `sfDoctrineGenerator` です。 -`param` エントリには生成モジュールのコンフィギュレーションオプションが用意されています。`model_class` オプションはこのモジュールに結びつけるモデルクラスを定義し、`theme` オプションはデフォルトのテーマを定義します。 +`param` エントリには生成モジュールのコンフィギュレーションオプションがとりそろえられています。`model_class` オプションはこのモジュールに結びつけるモデルクラスを定義し、`theme` オプションはデフォルトのテーマを定義します。 -メインコンフィギュレーションの変更は `config` エントリの下で行います。エントリは7つのセクションにわかれます: +メインコンフィギュレーションを変更する場所は `config` エントリの下側です。エントリは7つのセクションにわかれています。 * `actions`: リストとフォームで見つかるアクションのデフォルトコンフィギュレーション * `fields`: フィールドのデフォルトコンフィギュレーション * `list`: リストのコンフィギュレーション * `filter`: フィルタのコンフィギュレーション * `form`: 新規ページと編集フォームのコンフィギュレーション - * `edit`: 編集ページ固有のコンフィギュレーション - * `new`: 新規ページ固有のコンフィギュレーション + * `edit`: 編集ページ専用のコンフィギュレーション + * `new`: 新規ページ専用のコンフィギュレーション -デフォルトでは、セクションの定義はすべて空です。アドミンジェネレータはすべての実行可能なオプションに合わせて適切なデフォルトを用意します: +デフォルトでは、セクションの定義はすべて空です。アドミンジェネレータは実行可能なすべてのオプションに応じて適切なデフォルトを用意します。 [yml] generator: @@ -54,35 +54,35 @@ symfony のアドミンジェネレータによってモデルクラスのバッ edit: ~ new: ~ -この章では、アドミンジェネレータをカスタマイズするときに、`config` エントリを通して利用可能なすべてのオプションを説明します。 +この章では、アドミンジェネレータをカスタマイズするときにおいて、`config` エントリを通じて利用可能なすべてのオプションを説明します。 >**NOTE** ->何らかの説明がなければ、すべてのオプションは Propel と Doctrine の両方で同じように作用します。 +>何らかの説明がなければ、Propel と Doctrine の両方においてオプションの効果は同じです。 ### フィールド -多くのオプションはフィールドのリストを引数にとります。フィールドは実際のカラム名もしくは仮想的な名前になります。両方のケースにおいて、ゲッターをモデルクラスのなかで定義しなければなりません (`get` の後にラクダ記法のフィールド名をつけます)。 +多くのオプションはフィールドのリストを引数にとります。フィールドは実際のカラム名もしくは仮想的な名前になります。両方のケースにおいて、ゲッターをモデルクラスのなかで定義しなければなりません (`get` の後にキャメルケースのフィールド名をつけます)。 -アドミンジェネレータは、コンテキストに合わせてフィールドをレンダリングする方法を自己判断します。レンダリングをカスタマイズするには、パーシャルもしくはコンポーネントを作ります。慣習では、名前につけるプレフィックスは、パーシャルにはアンダースコア (`_`) で、コンポーネントにはチルダ (`~`) です: +アドミンジェネレータはコンテキストに応じてフィールドをレンダリングする方法を自分で選びます。レンダリングをカスタマイズするには、パーシャルもしくはコンポーネントを用意します。慣習では、名前につけるプレフィックスは、パーシャルにはアンダースコア (`_`) で、コンポーネントにはチルダ (`~`) です。 [yml] display: [_title, ~content] 上記の例において、`title` フィールドは `title` パーシャルによってレンダリングされ、`content` フィールドは `content` コンポーネントによってレンダリングされます。 -アドミンジェネレータはパーシャルとコンポーネントにいくつかのパラメータを渡します: +アドミンジェネレータはパーシャルとコンポーネントにいくつかのパラメータを渡します。 - * `new` と `edit` ページに対して: + * `new` と `edit` ページに渡されるパラメータ: * `form`: 現在のモデルオブジェクトに関連づけされているフォーム * `attributes`: ウィジェットに適用される HTML 属性の配列 - * `list`ページに対して: + * `list`ページに渡されるパラメータ: * `type`: `list` - * `MODEL_NAME`: 現在のオブジェクトのインスタンスで、`MODEL_NAME` はモデルクラスの名前の小文字バージョン。 - -`edit` もしくは `new` ページにおいて、2カラムレイアウトを保ちたい場合 (フィールドラベルとウィジェット)、パーシャルもしくはコンポーネントテンプレートは次のようになります: + * `MODEL_NAME`: 現在のオブジェクトのインスタンスで、MODEL_NAME はジェネレータオプションにセットされている単数形の名前です。値が明確に指定されていなければ、単数形の名前はアンダースコアで区切られたモデルクラスの名前になります (CamelCase は camel_case になります) + +`edit` もしくは `new` ページにおいて、2カラムレイアウトを保ちたい場合 (フィールドのラベルとウィジェット)、パーシャルもしくはコンポーネントテンプレートは次のようになります。 [php]
@@ -94,14 +94,14 @@ symfony のアドミンジェネレータによってモデルクラスのバッ ### オブジェクトプレースホルダ -オプションのなかにはモデルオブジェクトプレースホルダをとるものがあります。プレースホルダは `%%NAME%%` のパターンにしたがう文字列です。`NAME` はオブジェクトのゲッターメソッドに変換される任意の文字列になります (`get` の後にラクダ記法の `NAME` 文字列をつけます)。たとえば `%%title%%` は `$article->getTitle()` の値に置き換わります。実行時において、現在のコンテキストに関連するオブジェクトに合わせて、プレースホルダの値は動的に置き換わります。 +オプションのなかにはモデルオブジェクトプレースホルダを受けとるものがあります。プレースホルダは `%%NAME%%` のパターンにしたがう文字列です。`NAME` は任意の文字列で、オブジェクトのゲッターメソッドに変換されます (`get` の後にキャメルケースの `NAME` 文字列がつきます)。たとえば、`%%title%%` は `$article->getTitle()` の値に置き換わります。実行時において、現在のコンテキストに関連するオブジェクトに応じて、プレースホルダの値は動的に置き換わります。 >**TIP** ->モデルが別のモデルへの外部キーをもつとき、Propel と Doctrine は関連オブジェクトのゲッターを定義します。ほかのゲッターに関して、オブジェクトを文字列に変換する `__toString()` メソッドが定義されていれば、ゲッターをプレースホルダに使うことができます。 +>モデルのなかに別のモデルへの外部キーが存在していれば、Propel と Doctrine は関連オブジェクトのゲッターを定義します。その他のゲッターに関して、オブジェクトを文字列に変換する `__toString()` メソッドが定義されていれば、ゲッターをプレースホルダに用いることができます。 ### コンフィギュレーションの継承 -アドミンジェネレータのコンフィギュレーションはコンフィギュレーションカスケードの原則にしたがいます。継承ルールは次のとおりです: +アドミンジェネレータのコンフィギュレーションはコンフィギュレーションカスケードの原則にしたがいます。継承ルールは次のとおりです。 * `new` と `edit` は `form` を継承し、`form` は `fields` を継承します。 * `list` は `fields` を継承します。 @@ -109,88 +109,88 @@ symfony のアドミンジェネレータによってモデルクラスのバッ ### ~クレデンシャル~ -`credential` オプション (下記を参照) を使うことで、ユーザークレデンシャルに合わせて (リストとフォームの) アドミンジェネレータのアクションを隠すことができます。しかしながら、リンクもしくはボタンが現れない場合でも、不正なアクセスからアクションを守らなければなりません。アドミンジェネレータのクレデンシャル管理機能は表示だけを担当します。 +`credential` オプション (下記の節をご参照ください) を使えば、ユーザークレデンシャルに応じて (リストとフォームにおける) アドミンジェネレータのアクションを隠すことができます。しかしながら、リンクもしくはボタンが表示されないアクションであっても不正なアクセスからアクションを守らなければならないことがあります。アドミンジェネレータのクレデンシャル管理機能は表示の仕事だけを受け持ちます。 -list ページのカラムを隠すのにも `credential` オプションを使うことができます。 +`credential` オプションは list ページのカラムを隠すのにも使うことができます。 ### アクションのカスタマイズ -コンフィギュレーションが十分ではないとき、生成メソッドをオーバーライドできます: +既存のコンフィギュレーションがもの足りなければ、生成メソッドをオーバーライドできます。 | メソッド | 説明 | ---------------------- | ------------------------------------- | `executeIndex()` | `list` ビューアクション - | `executeFilter()` | フィルタを更新する + | `executeFilter()` | フィルタを更新します | `executeNew()` | `new` ビューアクション - | `executeCreate()` | 新しいレコードを作る + | `executeCreate()` | 新しいレコードを作ります | `executeEdit()` | `edit` ビューアクション - | `executeUpdate()` | レコードを更新する - | `executeDelete()` | レコードを削除する - | `executeBatch()` | バッチアクションを実行する - | `executeBatchDelete()` | `_delete` バッチアクションを実行する - | `processForm()` | レコードフォームを処理する - | `getFilters()` | 現在のフィルタを返す - | `setFilters()` | フィルタをセットする - | `getPager()` | list ページャを返す - | `getPage()` | ページャページを取得する - | `setPage()` | ページャページをセットする - | `buildCriteria()` | list の `Criteria` をビルドする - | `addSortCriteria()` | list のソート `Criteria` を追加する - | `getSort()` | 現在のソートカラムを返す - | `setSort()` | 現在のソートカラムをセットする + | `executeUpdate()` | レコードを更新します + | `executeDelete()` | レコードを削除します + | `executeBatch()` | バッチアクションを実行します + | `executeBatchDelete()` | `_delete` バッチアクションを実行します + | `processForm()` | レコードフォームを処理します + | `getFilters()` | 現在のフィルタを返します + | `setFilters()` | フィルタをセットします + | `getPager()` | list ページャを返します + | `getPage()` | ページャページを取得します + | `setPage()` | ページャページをセットします + | `buildCriteria()` | list の `Criteria` をビルドします + | `addSortCriteria()` | list のソート `Criteria` を追加します + | `getSort()` | 現在のソートカラムを返します + | `setSort()` | 現在のソートカラムをセットします ### テンプレートのカスタマイズ -それぞれの生成テンプレートを上書きできます: +それぞれの生成テンプレートをオーバーライドできます。 | テンプレート | 説明 - | ---------------------------- | --------------------------------------------- - | `_assets.php` | テンプレートに使う CSS と JS をレンダリングする - | `_filters.php` | フィルタボックスをレンダリングする - | `_filters_field.php` | 単独のフィルタフィールドをレンダリングする - | `_flashes.php` | フラッシュメッセージをレンダリングする - | `_form.php` | フォームを表示する - | `_form_actions.php` | フォームのアクションを表示する - | `_form_field.php` | 単独のフォームフィールドを表示する - | `_form_fieldset.php` | フォームのフィールドセットを表示する - | `_form_footer.php` | フォームのフッターを表示する - | `_form_header.php` | フォームのヘッダーを表示する - | `_list.php` | list を表示する - | `_list_actions.php` | list アクションを表示する - | `_list_batch_actions.php` | list バッチアクションを表示する - | `_list_field_boolean.php` | list のなかの単独のブール型フィールドを表示する - | `_list_footer.php` | list のフッターを表示する - | `_list_header.php` | list のヘッダーを表示する - | `_list_td_actions.php` | 列のオブジェクトアクションを表示する - | `_list_td_batch_actions.php` | 列のチェックボックスを表示する - | `_list_td_stacked.php` | 列のスタックレイアウトを表示する - | `_list_td_tabular.php` | list の単独フィールドを表示する - | `_list_th_stacked.php` | ヘッダーの単独のカラム名を表示する - | `_list_th_tabular.php` | ヘッダーの単独のカラム名を表示する - | `_pagination.php` | list パジネーション (ページ送り) を表示する - | `editSuccess.php` | `edit` ビューを表示する - | `indexSuccess.php` | `list` ビューを表示する - | `newSuccess.php` | `new` ビューを表示する + | ---------------------------- | -------------------------------------------------- + | `_assets.php` | テンプレートに使う CSS と JS をレンダリングします + | `_filters.php` | フィルタボックスをレンダリングします + | `_filters_field.php` | 単独のフィルタフィールドをレンダリングします + | `_flashes.php` | フラッシュメッセージをレンダリングします + | `_form.php` | フォームを表示します + | `_form_actions.php` | フォームのアクションを表示します + | `_form_field.php` | 単独のフォームフィールドを表示します + | `_form_fieldset.php` | フォームのフィールドセットを表示します + | `_form_footer.php` | フォームのフッターを表示します + | `_form_header.php` | フォームのヘッダーを表示します + | `_list.php` | list を表示します + | `_list_actions.php` | list アクションを表示します + | `_list_batch_actions.php` | list バッチアクションを表示します + | `_list_field_boolean.php` | list における単独のブール型フィールドを表示します + | `_list_footer.php` | list のフッターを表示します + | `_list_header.php` | list のヘッダーを表示します + | `_list_td_actions.php` | 列のオブジェクトアクションを表示します + | `_list_td_batch_actions.php` | 列のチェックボックスを表示します + | `_list_td_stacked.php` | 列のスタックレイアウトを表示します + | `_list_td_tabular.php` | list の単独フィールドを表示します + | `_list_th_stacked.php` | ヘッダーにおける単独のカラム名を表示します + | `_list_th_tabular.php` | ヘッダーにおける単独のカラム名を表示します + | `_pagination.php` | list のページ送りを表示します + | `editSuccess.php` | `edit` ビューを表示します + | `indexSuccess.php` | `list` ビューを表示します + | `newSuccess.php` | `new` ビューを表示します ### 見た目のカスタマイズ -生成されるテンプレートがたくさんの `class` と `id` 属性を定義するので、アドミンジェネレータの見た目は手軽にカスタマイズできます。 +生成されるテンプレートではさまざまな `class` と `id` 属性が定義されているので、アドミンジェネレータの見た目をかんたんにカスタマイズできます。 -`edit` もしくは `new` ページにおいて、それぞれのフィールドの HTML コンテナには次のクラスが用意されています: +`edit` もしくは `new` ページにおいて、それぞれのフィールドの HTML コンテナには次のクラスがとりそろえられています。 * `sf_admin_form_row` * フィールドの型に依存するクラス: `sf_admin_text`、`sf_admin_boolean`、`sf_admin_date`、`sf_admin_time` もしくは `sf_admin_foreignkey`。 * `sf_admin_form_field_COLUMN`。`COLUMN` はカラムの名前です。 -`list` ページにおいて、それぞれのフィールドの HTML コンテナには次のクラスが用意されています: +`list` ページにおいて、それぞれのフィールドの HTML コンテナには次のクラスがとりそろえられています。 * フィールドの型に依存するクラス: `sf_admin_text`、`sf_admin_boolean`、`sf_admin_date`、`sf_admin_time`、もしくは `sf_admin_foreignkey` * `sf_admin_form_field_COLUMN`。`COLUMN` はカラムの名前です。
-利用可能なコンフィギュレーションオプション --------------------------------------------- +利用可能なコンフィギュレーションオプションの一覧 +------------------------------------------------ * [`actions`](#chapter_06_actions) @@ -256,9 +256,9 @@ list ページのカラムを隠すのにも `credential` オプションを使 ### ~`label`~ -*デフォルト*: 人間にわかりやすいカラムの名前 +*デフォルト*: わかりやすい名前のカラム -`label` オプションはフィールドに使うラベルを定義します: +`label` オプションはフィールドに使われるラベルを定義します。 [yml] config: @@ -269,13 +269,13 @@ list ページのカラムを隠すのにも `credential` オプションを使 *デフォルト*: なし -`help` オプションはフィールドに表示するヘルプテキストを定義します。 +`help` オプションはフィールドに表示されるヘルプテキストを定義します。 ### ~`attributes`~ *デフォルト*: `array()` -`attributes` オプションはウィジェットに渡す HTML 属性を定義します: +`attributes` オプションはウィジェットに渡される HTML 属性を定義します。 [yml] config: @@ -286,7 +286,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 *デフォルト*: なし -`credentials` オプションはフィールドを表示するためにユーザーがもっていなければならない必須のクレデンシャルを定義します。クレデンシャルはオブジェクトのリストに対してのみ強制されます。 +`credentials` オプションはフィールドを表示するためにユーザーがもっていなければならない必須のクレデンシャルを定義します。クレデンシャルが強制されるアクションはリストにあげられているものにかぎられます。 [yml] config: @@ -295,42 +295,42 @@ list ページのカラムを隠すのにも `credential` オプションを使 is_online: { credentials: [[admin, moderator]] } >**NOTE** ->クレデンシャルは `security.yml` 設定ファイルと同じルールで定義されます。 +>クレデンシャルは `security.yml` ファイルと同じルールで定義されます。 ### ~`renderer`~ *デフォルト*: なし -`renderer` オプションはフィールドをレンダリングするために呼び出す PHP コールバックを定義します。定義されていれば、パーシャルもしくはコンポーネントのようなほかのフラグをオーバーライドします。 +`renderer` オプションはフィールドをレンダリングするために呼び出す PHP コールバックを定義します。定義されていれば、パーシャルやコンポーネントなどのフラグはオーバーライドします。 -コールバックは呼び出される際に `renderer_arguments` オプションで定義されているフィールドと引数の値を渡されます。 +コールバックは呼び出される際に `renderer_arguments` オプションで定義されているフィールドと引数の値を受けとります。 ### ~`renderer_arguments`~ *デフォルト*: `array()` -`renderer_arguments` オプションはフィールドをレンダリングする際に PHP の `renderer` コールバックに渡す引数を定義します。このオプションは `renderer` オプションが定義されている場合のみ使われます。 +`renderer_arguments` オプションはフィールドがレンダリングされる際に PHP の `renderer` コールバックに渡される引数を定義します。このオプションが適用されるのは `renderer` オプションが定義されている場合にかぎられます。 ### ~`type`~ *デフォルト*: バーチャルカラムの `Text` -`type` オプションはカラムの型を定義します。デフォルトでは、モデルで定義されているカラムの型を使いますが、バーチャルカラムを作る場合、デフォルトの `Text` 型を有効な型のうちの1つでオーバーライドできます: +`type` オプションはカラムの型を定義します。デフォルトでは、モデルで定義されているカラムの型が使われますが、バーチャルカラムを作るのであれば、デフォルトの `Text` 型を有効な型のうちの1つでオーバーライドできます。 * `ForeignKey` * `Boolean` * `Date` * `Time` * `Text` - * `Enum` (Doctrine のみで利用可能) + * `Enum` (Doctrine 限定) ### ~`date_format`~ *デフォルト*: `f` -`date_format` オプションは日付を表示する際に使うフォーマットを定義します。値は `sfDateFormat` クラスによって認識されるフォーマットです。フィールドの型が `Date` である場合はこのオプションは使われません。 +`date_format` オプションは日付の表示に使われるフォーマットを定義します。値は `sfDateFormat` クラスによって認識されるフォーマットです。フィールドの型が `Date` である場合はこのオプションは適用されません。 -フォーマットには次のトークンを使うことができます: +次のトークンをフォーマットに使うことができます。 * `G`: Era * `y`: year @@ -353,7 +353,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 `actions` --------- -フレームワークは組み込みのアクションをいくつか定義します。これらすべての名前にはプレフィックスのアンダースコア (`_`) がつきます。それぞれのアクションはこの節で説明されているオプションでカスタマイズできます。`list`、`edit` もしくは `new` エントリでアクションを定義する場合にも同じオプションを使うことができます。 +さまざまなアクションがあらかじめ定義され、組み込まれています。これらすべての名前にはプレフィックスのアンダースコア (`_`) がつきます。それぞれのアクションはこの節で説明されているオプションでカスタマイズできます。アクションを `list`、`edit` もしくは `new` エントリで定義する場合にも同じオプションを使うことができます。 ### ~`label`~ @@ -365,31 +365,31 @@ list ページのカラムを隠すのにも `credential` オプションを使 *デフォルト*: アクションの名前に応じて定義されます。 -`action` オプションは実行するアクションの名前を定義します (プレフィックスの `execute` はつけません)。 +`action` オプションは実行するアクションの名前を定義します (プレフィックスの `execute` はつきません)。 ### ~`credentials`~ *デフォルト*: なし -`credentials` オプションはアクションを表示するためにユーザーがもたなければならないクレデンシャルを定義します。 +`credentials` オプションはアクションを表示するためにユーザーがもっていなければならないクレデンシャルを定義します。 >**NOTE** ->クレデンシャルは `security.yml` 設定ファイルと同じルールで定義されます。 +>クレデンシャルは `security.yml` ファイルと同じルールで定義されます。 `list` ------ ### ~`title`~ -*デフォルト*: 人間にわかりやすく、サフィックスが「List」であるモデルクラスの名前 +*デフォルト*: わかりやすい名前で、サフィックスが「List」であるモデルクラス `title` オプションは list ページのタイトルを定義します。 ### ~`display`~ -*デフォルト*: すべてのモデルカラム、順序はスキーマファイルでの定義順 +*デフォルト*: すべてのモデルカラム、表示順序はスキーマファイルの定義順と同じ -`display` オプションは list で表示する順序つきカラムの配列を定義します。 +`display` オプションは list ページに表示されるカラムの順序つき配列を定義します。 カラムの名前の前に等号 (`=`) をつければ、文字列は現在のオブジェクトの `edit` ページに進むリンクに変換されるようになります。 @@ -399,13 +399,13 @@ list ページのカラムを隠すのにも `credential` オプションを使 display: [=name, slug] >**NOTE** ->カラムを隠す `hide` オプションも参照してください。 +>カラムを隠す `hide` オプションもご参照ください。 ### ~`hide`~ *デフォルト*: なし -`hide` オプションは list から隠すカラムを定義します。カラムを隠すのに `display` オプションで表示されるカラムを指定するよりも、こちらのほうが作業が少なくて済むことがあります: +`hide` オプションは list ページから隠すカラムを定義します。表示されるカラムを `display` オプションで指定するよりも、こちらのほうが作業が少なくてすむことがあります。 [php] config: @@ -413,7 +413,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 hide: [created_at, updated_at] >**NOTE** ->`display` と `hide` オプションの両方が提供される場合、`hide` オプションは無視されます。 +>`display` と `hide` オプションの両方が指定されている場合、`hide` オプションは無視されます。 ### ~`layout`~ @@ -421,20 +421,20 @@ list ページのカラムを隠すのにも `credential` オプションを使 *利用可能な値*: ~`tabular`~ もしくは ~`stacked`~ -`layout` オプションは list を表示するのに使うレイアウトを定義します。 +`layout` オプションは list ページの表示に使われるレイアウトを定義します。 -`tabular` レイアウトでは、それぞれのカラムの値は独自テーブルのカラムに入っています。 +`tabular` レイアウトでは、独自のテーブルのカラムにそれぞれのカラムの値が入ります。 -`stacked` レイアウトでは、それぞれのオブジェクトは `params` オプション (下記を参照) で定義されている単独の文字列で表されます。 +`stacked` レイアウトでは、それぞれのオブジェクトは `params` オプションで定義されている単独の文字列であらわされます (下記の節をご参照ください)。 >**NOTE** ->`display` オプションは `stacked` レイアウトを使う際にも必要です。ユーザーがソートできるカラムはこのオプションによって定義されるからです。 +>ユーザーがソートできるカラムは `display` オプションによって定義されるので、`stacked` レイアウトを使う場合にもこのオプションは必要です。 ### ~`params`~ *デフォルト*: なし -`params` オプションは `stacked` レイアウトに使われる HTML 文字列のパターンを定義します。この文字列にはモデルオブジェクトプレースホルダを入れることができます: +`params` オプションは `stacked` レイアウトに使われる HTML 文字列のパターンを定義します。この文字列にモデルオブジェクトのプレースホルダを埋め込むことができます。 [yml] config: @@ -448,7 +448,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 *デフォルト*: なし -`sort` オプションはデフォルトの sort カラムを定義します。このオプションは2つの要素: カラムの名前とソートの順序 (`asc` もしくは `desc`) から成り立ちます。 +`sort` オプションはデフォルトの sort カラムを定義します。このオプションはカラムの名前とソートの順序 (`asc` もしくは `desc`) からなります。 [yml] config: @@ -459,54 +459,61 @@ list ページのカラムを隠すのにも `credential` オプションを使 *デフォルト*: `20` -`max_per_page` オプションは1つのページで表示するオブジェクトの最大数を定義します。 +`max_per_page` オプションは1ページに表示されるオブジェクトの最大数を定義します。 ### ~`pager_class`~ *デフォルト*: Propel では `sfPropelPager`、Doctrine では `sfDoctrinePager` -`pager_class` オプションは list を表示する際に使われるページャクラスを定義します。 +`pager_class` オプションは list ページが表示される際に使われるページャクラスを定義します。 ### ~`batch_actions`~ *デフォルト*: `{ _delete: ~ }` -`batch_actions` オプションは list のオブジェクト選択で実行できるアクションのリストを定義します。 +`batch_actions` オプションは list ページにおいてオブジェクトを選ぶために実行されるアクションのリストを定義します。 -`action` が定義されていない場合、アドミンジェネレータは `executeBatch` をプレフィックスとするラクダ記法の名前をもつメソッドを探します。 +`action` オプションが定義されていない場合、アドミンジェネレータは `executeBatch` をプレフィックスとするキャメルケースの名前をもつメソッドを探します。 -実行されるメソッドは `ids` リクエストパラメータを通して選択されるオブジェクトの主キーを受け取ります。 +実行されるメソッドは `ids` リクエストパラメータを通じて選ばれたオブジェクトのプライマリキーを受けとります。 >**TIP** ->バッチアクションを無効にするには、このオプションを空の配列: `{}` にセットします。 +>バッチアクションを無効にするには、このオプションに空の配列 (`{}`) にセットします。 ### ~`object_actions`~ *デフォルト*: `{ _edit: ~, _delete: ~ }` -`object_actions` オプションは list のそれぞれのオブジェクトで実行可能なアクションのリストを定義します。 +`object_actions` オプションはリストのそれぞれのオブジェクトで実行できるアクションのリストを定義します。 + + [yml] + object_actions: + moveUp: { label: "move up", action: "moveUp" } + moveDown: { label: "move down", action: "moveDown" } + _edit: ~ + _delete: ~ -`action` が定義されていない場合、アドミンジェネレータは、`executeList` をプレフィックスとするラクダ記法の名前をもつメソッドを探します。 +`action` オプションが定義されていなければ、アドミンジェネレータは `executeList` をプレフィックスとするキャメルケースの名前をもつメソッドを探します。 >**TIP** ->オブジェクトアクションを無効にするには、このオプションを空の配列: `{}` にセットします。 +>オブジェクトアクションを無効にするには、このオプションに空の配列 (`{}`) をセットします。 ### ~`actions`~ *デフォルト*: `{ _new: ~ }` -新しいオブジェクトの作成のように、`actions` オプションはオブジェクトを受け取らないアクションを定義します。 +`actions` オプションはオブジェクトを受けとらないアクションを定義します。用例としてオブジェクトの新規作成をあげることができます。 -`action` が定義されていない場合、アドミンジェネレータは、`executeList` をプレフィックスとするラクダ記法の名前のメソッドを探します。 +`action` オプションが定義されていない場合、アドミンジェネレータは `executeList` をプレフィックスとするキャメルケースの名前のメソッドを探します。 >**TIP** ->オブジェクトアクションの機能を無効にするには、オプションを空の配列: `{}` にセットします。 +>オブジェクトアクションの機能を無効にするには、オプションに空の配列 (`{}`) をセットします。 ### ~`peer_method`~ *デフォルト*: `doSelect` -`peer_method` オプションは list で表示するオブジェクトを検索するために呼び出すメソッドを定義します。 +`peer_method` オプションは list ページで表示されるオブジェクトを検索するために呼び出すメソッドを定義します。 >**CAUTION** >このオプションは Propel 専用です。Doctrine では `table_method` オプションを使います。 @@ -515,7 +522,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 *デフォルト*: `doSelect` -`table_method` オプションは list で表示するオブジェクトを検索するために呼び出すメソッドを定義します。 +`table_method` オプションは list ページで表示されるオブジェクトを検索するために呼び出すメソッドを定義します。 >**CAUTION** >このオプションは Doctrine 専用です。Propel では `peer_method` オプションを使います。 @@ -541,41 +548,41 @@ list ページのカラムを隠すのにも `credential` オプションを使 `filter` -------- -`filter` セクションは list ページに表示されるフォームをフィルタリングする方法を指示するためのコンフィギュレーションを定義します。 +`filter` セクションは list ページに表示されるフォームにフィルタをかける方法を指定するためのコンフィギュレーションを定義します。 ### ~`display`~ -*デフォルト*: フィルタフォームクラスで定義されているすべてのフィールド、順序は定義順と同じ +*デフォルト*: フィルタフォームクラスで定義されているすべてのフィールド、表示順序は定義順と同じ -`display` オプションは表示するフィールドの順序つきリストを定義します。 +`display` オプションは表示されるフィールドの順序つきリストを定義します。 >**TIP** ->フィルタフィールドはつねにオプションで、表示するフィールドを設定するためにフィルタフォームクラスをオーバーライドする必要はありません。 +>フィルタフィールドはつねにオプションで、表示されるフィールドを設定するためにフィルタフォームクラスをオーバーライドする必要はありません。 ### ~`class`~ *デフォルト*: `FormFilter` をサフィックスとするモデルクラスの名前 -`class` オプションは `filter` フォームに使うフォームクラスを定義します。 +`class` オプションは `filter` フォームに使われるフォームクラスを定義します。 >**TIP** ->フィルタリングを完全に除外するには、このオプションを `false` にセットします。 +>フィルタリングを完全に除外するには、このオプションに `false` をセットします。 `form` ------ -`form` セクションは `edit` と `new` セクションのフォールバックとしてのみ存在します (最初の継承ルールを参照)。 +`form` セクションは `edit` と `new` セクションのフォールバックとしての役目を果たすためだけに用意されています (最初の継承ルールをご参照ください)。 >**NOTE** >フォームセクション (`form`、`edit` と `new`) に関して、`label` と `help` オプションはフォームクラスで定義されているものをオーバーライドします。 ### ~`display`~ -*デフォルト*: フォームクラスで定義されているすべてのクラス。順序は定義の順序と同じ。 +*デフォルト*: フォームクラスで定義されているすべてのクラス。表示順序は定義順と同じ。 -`display` オプションは表示するフィールドの順序つきリストを定義します。 +`display` オプションは表示されるフィールドの順序つきリストを定義します。 -このオプションは複数のフィールドをグループにまとめるのにも使うことができます: +このオプションは複数のフィールドを1つのグループにまとめるために使うこともできます。 [yml] # apps/backend/modules/model/config/generator.yml @@ -585,19 +592,19 @@ list ページのカラムを隠すのにも `credential` オプションを使 Content: [title, body, author] Admin: [is_published, expires_at] -上記のコンフィギュレーションは2つのグループ (`Content` と `Admin`) を定義します。それぞれのグループには、フォームフィールドのサブセットが用意されています。 +上記のコンフィギュレーションは2つのグループ (`Content` と `Admin`) を定義しています。それぞれのグループにフォームフィールドのサブセットが用意されています。 >**CAUTION** ->モデルフォームで定義されているすべてのフィールドは `display` オプションに存在しなければなりません。存在しなければ、予期しないバリデーションエラーになる可能性があります。 +>モデルフォームで定義されているすべてのフィールドは `display` オプションに存在していなければなりません。存在していなければ、予期せぬバリデーションエラーが発生する可能性があります。 ### ~`class`~ *デフォルト*: `Form` をサフィックスとするモデルクラスの名前 -`class` オプションは `edit` と `new` ページに使うフォームクラスを定義します。 +`class` オプションは `edit` と `new` ページに使われるフォームクラスを定義します。 >**TIP** ->`class` オプションは `new` と `edit` セクションの両方で定義できますが、1つのクラスを使い、条件ロジックで対応するほうがよいやり方です。 +>`class` オプションは `new` と `edit` セクションの両方で定義できますが、1つのクラスを使い、条件ロジックで対処するほうがよいやりかたです。 `edit` ------ @@ -606,7 +613,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 ### ~`title`~ -*デフォルト*: 人間にわかりやすく `Edit` をサフィックスとするモデルクラスの名前 +*デフォルト*: `Edit` をサフィックスとするモデルクラスの名前 `title` オプションは edit ページのタイトルを定義します。このオプションはモデルオブジェクトのプレースホルダをとることができます。 @@ -623,7 +630,7 @@ list ページのカラムを隠すのにも `credential` オプションを使 ### ~`title`~ -*デフォルト*: 人間にわかりやすく `New` をサフィックスとするモデルクラスの名前 +*デフォルト*: `New` をサフィックスとするモデルクラスの名前 `title` オプションは新しいページのタイトルを定義します。このオプションはモデルオブジェクトのプレースホルダをとることができます。 diff --git a/reference/ja/07-Databases.markdown b/reference/ja/07-Databases.markdown index ad83d50..ffe2376 100644 --- a/reference/ja/07-Databases.markdown +++ b/reference/ja/07-Databases.markdown @@ -1,25 +1,25 @@ databases.yml 設定ファイル ========================== -~`databases.yml`~ では、データベースコネクション (接続) のコンフィギュレーションを変更できます。この設定ファイルは symfony に搭載されている ORM である Propel と Doctrine の両方で使われます。 +データベースコネクション (接続) のコンフィギュレーションは ~`databases.yml`~ ファイルのなかで変更できます。この設定ファイルは symfony に搭載されている ORM の Propel と Doctrine の両方で使われます。 -プロジェクトのメイン設定ファイルである `databases.yml` は `config/` ディレクトリで見つかります。 +プロジェクトのメイン設定ファイルである `databases.yml` ファイルは `config/` ディレクトリに配置されています。 >**NOTE** ->ほとんどの場合、プロジェクトのすべてのアプリケーションは同じデータベースを共有します。このことがデータベースのメイン設定ファイルがプロジェクトの `config/` ディレクトリに存在する理由です。もちろんアプリケーションの `config` ディレクトリのなかで `databases.yml` 設定ファイルを定義することで、デフォルトコンフィギュレーションをオーバーライドできます。 +>たいていのプロジェクトにおいて、すべてのアプリケーションは同じデータベースを共有しています。このことがデータベースのメイン設定ファイルがプロジェクトの `config/` ディレクトリに配置されている理由です。もちろん、`databases.yml` ファイルをアプリケーションの `config/` ディレクトリに配置すれば、デフォルトコンフィギュレーションをオーバーライドできます。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`databases.yml` ファイルでは、**環境が認識され**、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`databases.yml` ファイルでは、**環境**が認識され、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 -`databases.yml` のなかのそれぞれのコネクションでは、データベースオブジェクトを設定するために使う名前、データベースハンドラクラスの名前、パラメータ (`param`) の設定を指定しなければなりません: +`databases.yml` ファイルのなかのそれぞれのコネクションにおいて、データベースオブジェクトの初期化に使われる名前、データベースハンドラクラスの名前、パラメータ (`param`) をセットしなければなりません。 [yml] CONNECTION_NAME: class: CLASS_NAME param: { ARRAY OF PARAMETERS } -`class` クラスは `sfDatabase` 基底クラスを継承します。 +`class` クラスは `sfDatabase` 基底クラスを継承しなければなりません。 -データベースハンドラクラスがオートロードされない場合、ファクトリが作られる前に `file` パスが定義され、自動的にインクルードされます: +データベースハンドラクラスがオートロードされていなければ、ファクトリが作られる前に `file` パスが定義され、自動的にインクルードされます。 [yml] CONNECTION_NAME: @@ -27,12 +27,12 @@ databases.yml 設定ファイル file: ABSOLUTE_PATH_TO_FILE >**NOTE** ->`databases.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfDatabaseConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`databases.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfDatabaseConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 - >**TIP** ->データベースのコンフィギュレーションを変更する作業は `database:configure` タスクでも行うことができます。このタスクは引数に渡された値にしたがって `databases.yml` を更新します。 +>データベースコンフィギュレーションの変更は `database:configure` タスクでも実行することができます。このタスクは引数に渡された値に応じて `databases.yml` ファイルを更新します。 Propel ------ @@ -70,7 +70,7 @@ Propel persistent: true pooling: true -次のパラメータは `param` セクションの下でカスタマイズできます: +次のパラメータは `param` セクションのなかでカスタマイズできます。 | キー | 説明 | デフォルト | | ------------ | ----------------------------| -------------- | @@ -79,12 +79,12 @@ Propel | `username` | データベースのユーザー名 | - | | `password` | データベースのパスワード | - | | `pooling` | プーリングを有効にするか | `true` | - | `encoding` | デフォルトのエンコーディング | `utf8` | - | `persistent` | 永続的なコネクションを作成するか | `false` | + | `encoding` | デフォルトのエンコーディング | `utf8` | + | `persistent` | 永続的なコネクションを作成するか | `false` | | `options` | Propel オプションのセット | - | | `debug` | `DebugPDO` クラスのオプション| n/a | -`debug` エントリは Propel の[ドキュメント](http://www.propelorm.org/docs/api/1.4/runtime/propel-util/DebugPDO.html#class_details)で説明されているすべてのオプションを定義します。次の YAML は利用可能なオプションを示します: +`debug` エントリでは Propel の[ドキュメント](http://www.propelorm.org/docs/api/1.4/runtime/propel-util/DebugPDO.html#class_details)に記載されているすべてのオプションを定義できます。次の YAML コードは利用可能なオプションを示しています。 [yml] debug: @@ -127,7 +127,7 @@ Doctrine seqname_format: %s_seq tblname_format: %s -次のパラメータは `param` セクションの下でカスタマイズできます: +次のパラメータは `param` セクションのなかでカスタマイズできます。 | キー | 説明 | デフォルト | | ------------ | --------------------------- | ------------ | @@ -137,13 +137,17 @@ Doctrine | `encoding` | デフォルトのエンコーディング | `utf8` | | `attributes` | Doctrine 属性のセット | - | -次の属性は `attributes` セクションの下でカスタマイズできます: +次の属性は `attributes` セクションのなかでカスタマイズできます。 | キー | 説明 | デフォルト | | ------------------ | -------------------------------------- | ------------ | - | `quote_identifier` | 識別子をクォートでラッピングするか | `false` | + | `quote_identifier` | 識別子をクォートで囲むか | `false` | | `use_native_enum` | ネイティブの列挙型を使うか | `false` | - | `validate` | データバリデーションを有効にするかどうか | `true` | + | `validate` | データバリデーションを有効にするかどうか | `true` | | `idxname_format` | インデックス名のフォーマット | `%s_idx` | | `seqname_format` | シーケンス名のフォーマット | `%s_seq` | | `tblname_format` | テーブル名のフォーマット | `%s` | + + +>**TIP** +>*訳注*: `attributes` セクションのなかで文字集合と照合順序 (`default_table_charset` と `default_table_collate`) および MySQL を利用している場合はストレージエンジンのデフォルトもカスタマイズできます (`default_table_type`)。 diff --git a/reference/ja/08-Security.markdown b/reference/ja/08-Security.markdown index caf8f43..dc6b641 100644 --- a/reference/ja/08-Security.markdown +++ b/reference/ja/08-Security.markdown @@ -1,86 +1,86 @@ security.yml 設定ファイル -======================== +========================= -~`security.yml`~ 設定ファイルでは、symfony アプリケーションの認証 (authentication) と承認 (authorization) を記述します。 +アプリケーションの認証 (authentication) と承認 (authorization) の要件は ~`security.yml`~ ファイルに記述します。 >**TIP** ->`security.yml` ファイルからのコンフィギュレーション情報は [`user`](#chapter_05_user) ファクトリクラス (デフォルトは `sfBasicSecurityUser`) によって使われます。認証と承認の実行は `security` [フィルタ](#chapter_12_security)によって行われます。 +>`security.yml` ファイルのコンフィギュレーションは [`user`](#chapter_05_user) ファクトリクラスによって使われます (デフォルトは `sfBasicSecurityUser`)。認証と承認の実行は `security` [フィルタ](#chapter_12_security)が担います。 -アプリケーションが作られるとき、symfony はデフォルトの `security.yml` ファイルをアプリケーションの `config/` ディレクトリに生成します。このファイルでは、アプリケーション全体のセキュリティを記述します (`default` キーの下): +デフォルトでは、`security.yml` ファイルはアプリケーションの `config/` ディレクトリに配置されています。アプリケーション全体のセキュリティ要件はこのファイルに記述します (`default` キーの下)。 [yml] default: is_secure: off -[設定ファイルの原則の章](#chapter_03)で説明したように、`security.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`security.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 -アプリケーションのデフォルトコンフィギュレーションをオーバーライドするには、モジュールの `config/` ディレクトリのなかで `security.yml` ファイルを作ります。メインキーはアクションの名前で、プレフィックスの `execute` はつけません (たとえば `executeIndex` メソッドであれば `index`)。 +アプリケーションのデフォルトコンフィギュレーションをオーバーライドするには、 `security.yml` ファイルをモジュールの `config/` ディレクトリに配置します。メインキーはアクションの名前で、プレフィックスの `execute` はつけません (たとえば `executeIndex` メソッドであれば `index`)。 -アクションがセキュアであるかどうかを判断するために、symfony は次の順序で情報を探します: +アクションにアクセス制限がかけられているかどうかを判断するために、symfony は次の順序で情報を探します。 - * 存在しているのであれば、モジュール設定ファイルでの特定のアクションのコンフィギュレーション; + * モジュールの設定ファイルに存在しているのであれば、特定のアクションのコンフィギュレーション。 - * 存在しているのであれば、モジュール設定ファイルでのモジュール全体のコンフィギュレーション (`all` キーの下); + * モジュールの設定ファイルに存在しているのであれば、モジュール全体のコンフィギュレーション (`all` キーの下)。 * アプリケーションのデフォルトコンフィギュレーション (`default` キーの下)。 アクションにアクセスする際に必要なクレデンシャルを決めるのに同じ優先ルールが適用されます。 >**NOTE** ->`security.yml` 設定ファイルは PHP ファイルとしてキャッシュできます。処理は ~`sfSecurityConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`security.yml` ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfSecurityConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 ~認証~ ------ -`security.yml` のコンフィギュレーションはアプリケーションごとにインストールされ、デフォルトでは、すべてのユーザーのアクセスが許可されます: +`security.yml` ファイルのコンフィギュレーションはアプリケーションごとにインストールされ、デフォルトでは、すべてのユーザーのアクセスが許可されています。 [yml] default: is_secure: false -アプリケーション全体ですべてのユーザーの認証が必須にするには、アプリケーションの ~`security.yml`~ ファイルのなかで、`is_secure` キーを `true` にセットします。 +すべてのユーザーの認証をアプリケーション全体で必須にするには、アプリケーションの ~`security.yml`~ ファイルのなかで `is_secure` キーに `true` をセットします。 >**NOTE** ->認証されていないユーザーがセキュアなアクションにアクセスしようとすると、symfony はリクエストを `settings.yml` で指定されている `login` アクションに転送します。 +>アクセス制限がかけられたアクションに認証されていないユーザーがアクセスしようとすると、リクエストは `settings.yml` ファイルで指定されている `login` アクションに転送されます。 -モジュールの認証要件を修正するには、`config/` ディレクトリのなかで `security.yml` を作り、`all` キーを定義します: +モジュールの認証要件を修正するには、 `security.yml` ファイルを `config/` ディレクトリに配置し、`all` キーを定義します。 [yml] all: is_secure: true -モジュールの単独のアクションの認証要件を修正するには、モジュールの `config/` ディレクトリのなかで `security.yml` ファイルを作り、アクションの名前の下側でキーを定義します: +個別のアクションの認証要件を修正するには、`security.yml` ファイルをモジュールの `config/` ディレクトリに配置し、アクションの名前の下側でキーを定義します。 [yml] index: is_secure: false >**TIP** ->login アクションをセキュアにすることはできません。これは無限ループを避けるためです。 +>無限ループに陥らないようにするため、login アクションにアクセス制限をかけられないようになっています。 ~承認~ ------ -ユーザーが認証されているとき、*~クレデンシャル~*を定義することで、一部のアクションへのアクセスを細かく制限できます。クレデンシャルが定義されているとき、ユーザーはアクションにアクセスするための必須クレデンシャルをもたなければなりません: +*~クレデンシャル~*を定義することで、一部のアクションにアクセスできる認証ずみユーザーを細かく指定できます。クレデンシャルが定義されている場合、ユーザーはアクションにアクセスするための必須クレデンシャルをもっていなければなりません。 [yml] all: is_secure: true credentials: admin -symfony のクレデンシャルシステムはシンプルで強力です。クレデンシャルはアプリケーションのセキュリティモデルを記述するために必要なものを表現できる文字列です (グループもしくはパーミッションのようなもの)。 +symfony のクレデンシャルシステムはシンプルで強力です。クレデンシャルはアプリケーションのセキュリティモデルをあらわす文字列です (グループもしくはパーミッションのようなもの)。 -複雑なクレデンシャル要件を記述できるようにするために、`credentials` キーは配列記法を使ったブール演算をサポートします。 +複雑なクレデンシャル要件をわかりやすく示すことができるようにするために、`credentials` キーの設定のなかで配列記法を使ったブール演算がサポートされています。 -ユーザーがクレデンシャル A **かつ**クレデンシャル B をもたなければならない場合、これらのクレデンシャルを角かっこで囲みます: +ユーザーがクレデンシャル A **かつ**クレデンシャル B をもっていなければならないことを示すには、これらのクレデンシャルを角かっこで囲みます。 [yml] index: credentials: [A, B] -ユーザーがクレデンシャル A **または**クレデンシャル B をもたなければならないとき、これらのクレデンシャルを2つのペアの角かっこで囲みます: +ユーザーがクレデンシャル A **または**クレデンシャル B をもっていなければならないことを示すには、これらのクレデンシャルを2つのペアの角かっこで囲みます。 [yml] index: credentials: [[A, B]] -任意の数のクレデンシャルによって任意の種類のブール式を表すために、複数のかっこを混ぜることもできます。 +任意の数のクレデンシャルによって任意の種類のブール式を示すために、複数のかっこを組み合わせることもできます。 diff --git a/reference/ja/09-Cache.markdown b/reference/ja/09-Cache.markdown index a84b79b..afe0501 100644 --- a/reference/ja/09-Cache.markdown +++ b/reference/ja/09-Cache.markdown @@ -1,12 +1,12 @@ cache.yml 設定ファイル -===================== +====================== -~`cache.yml`~ 設定ファイルでは、ビューレイヤーのキャッシュコンフィギュレーションを記述します。この設定ファイルは `settings.yml` で [`cache`](#chapter_04_sub_cache) 設定が有効な場合のみアクティブになります。 +ビューレイヤーのキャッシュコンフィギュレーションは ~`cache.yml`~ ファイルのなかで記述します。`settings.yml` ファイルのなかで [`cache`](#chapter_04_sub_cache) 設定が有効になっている場合にかぎり、この設定ファイルは有効です。 >**TIP** ->クラスのコンフィギュレーションはキャッシュのために使われ、関連コンフィギュレーションの変更は [`view_cache_manager`](#chapter_05_view_cache_manager) と `factories.yml` 設定ファイルの [`view_cache`](#chapter_05_view_cache) セクションで行います。 +>クラスのコンフィギュレーションはキャッシュに使われ、関連するコンフィギュレーションを変更する場所は `factories.yml` ファイルの [`view_cache`](#chapter_05_view_cache) と [`view_cache_manager`](#chapter_05_view_cache_manager) セクションです。 -アプリケーションが作られるとき、symfony はデフォルトの `cache.yml` ファイルをアプリケーションの `config/` ディレクトリに生成します。このファイルでは、アプリケーション全体のキャッシュを記述します (`default` キーの下)。デフォルトでは、キャッシュはグローバルで `false` にセットされています: +デフォルトでは、`cache.yml` ファイルはアプリケーションの `config/` ディレクトリに配置されています。アプリケーション全体におけるキャッシュの要件はこのファイルに記述します (`default` キーの下)。デフォルトでは、グローバルなキャッシュは無効です。 [yml] default: @@ -15,25 +15,25 @@ cache.yml 設定ファイル lifetime: 86400 >**TIP** ->デフォルトでは、`enabled` 設定は `false` にセットされているので、キャッシュを個別に有効にする必要があります。ほかには、グローバルキャッシュを有効にし、キャッシュする必要のない特定のページでキャッシュを無効にする方法もあります。作業量が少ないほうを選ぶとよいでしょう。 +>デフォルトでは、`enabled` 設定に `false` がセットされているので、キャッシュを個別に有効にする必要があります。別の方法として、グローバルキャッシュを有効にしてから、キャッシュする必要のない特定のページでキャッシュを無効にすることもできます。作業が少ないほうを選ぶとよいでしょう。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`cache.yml` ファイルでは、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`cache.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 >**NOTE** ->`cache.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfCacheConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`cache.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfCacheConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 -モジュールのためにアプリケーションのデフォルトコンフィギュレーションをオーバーライドするには、モジュールの `config/` ディレクトリのなかで `cache.yml` ファイルを作ります。メインキーはアクションの名前で、プレフィックスの `execute` をつけません (たとえば `executeIndex` メソッドであれば `index`)。名前にプレフィックスのアンダースコア (`_`) をつければ、パーシャルもしくはコンポーネントもキャッシュできます。 +モジュールのためにアプリケーションのデフォルトコンフィギュレーションをオーバーライドするには、`cache.yml` ファイルをモジュールの `config/` ディレクトリに配置します。メインキーはアクションの名前で、プレフィックスの `execute` はつけません (たとえば `executeIndex` メソッドであれば `index`)。名前にプレフィックスのアンダースコア (`_`) をつければ、パーシャルもしくはコンポーネントもキャッシュできます。 -アクションをキャッシュするかどうかを決めるのに、symfony は次の順序で情報を探します: +symfony はアクションをキャッシュするかどうかを決めるために次の順序でコンフィギュレーションの情報を探します。 - * 存在しているのであれば、モジュール設定ファイルでの特定のアクション、パーシャル、コンポーネントのコンフィギュレーション; + * モジュールの設定ファイルに存在しているのであれば、特定のアクション、パーシャル、コンポーネントのコンフィギュレーション - * 存在しているのであれば、モジュール設定ファイルでのモジュール全体のコンフィギュレーション (`all` キーの下); + * モジュールの設定ファイルに存在しているのであれば、モジュール全体のコンフィギュレーション (`all` キーの下) * アプリケーションのデフォルトコンフィギュレーション (`default` キーの下) >**CAUTION** ->コンフィギュレーションに関わらず、クエリ文字列の `GET` パラメータで送信されるリクエストや、`POST`、`PUT` もしくは `DELETE` メソッドで投稿されるリクエストはキャッシュされることはけっしてありません。 +>コンフィギュレーションにかかわらず、クエリ文字列のなかの `GET` パラメータをともなうリクエストや、`POST`、`PUT` もしくは `DELETE` メソッドによるリクエストはキャッシュとして保存されることはけっしてありません。 ~`enabled`~ ----------- @@ -47,17 +47,17 @@ cache.yml 設定ファイル *デフォルト*: `false` -`with_layout` 設定はキャッシュの対象をページ全体 (`true`) かアクションだけ (`false`) にするのかを決めます。 +`with_layout` 設定はキャッシュの対象をページ全体 (`true`) かアクション限定 (`false`) にするのかを決めます。 >**NOTE** ->`with_layout` オプションはパーシャルとコンポーネントキャッシュには反映されません。これらをレイアウトによって飾りつけることができないからです。 +>パーシャルとコンポーネントキャッシュには `with_layout` オプションの効果はありません。これらをレイアウトによってデコレートすることができないからです。 ~`lifetime`~ ------------ *デフォルト*: `86400` -`lifetime` 設定はサーバーサイドキャッシュの有効期間を秒単位で定義します (`86400`秒は1日に等しい)。 +`lifetime` 設定はサーバーサイドキャッシュの有効期間を秒単位で定義します (1日を秒数に換算すると`86400`秒です)。 ~`client_lifetime`~ ------------------- @@ -66,18 +66,18 @@ cache.yml 設定ファイル `client_lifetime` 設定はクライアントサイドキャッシュの有効期間を秒単位で定義します。 -すでに `Last-Modified` もしくは `Expires` ヘッダーがセットされていないかぎり、この設定は `Expires` ヘッダーと `max-cache` キャッシュコントロール変数を自動的にセットするために使われます。 +すでに `Last-Modified` もしくは `Expires` ヘッダーがセットされていないかぎり、`Expires` ヘッダーと `max-cache` キャッシュコントロール変数を自動的にセットするためにこの設定が使われます。 -この値を`0`にセットすることでクライアントサイドキャッシュを無効にできます。 +この設定に`0`をセットすれば、クライアントサイドキャッシュは無効になります。 ~`contextual`~ -------------- *デフォルト*: `false` -`contextual` 設定はキャッシュが現在のページのコンテキストに依存するかどうかを決めます。それゆえ、この設定が反映されるのはパーシャルとコンポーネントによって使われるときだけです。 +`contextual` 設定はキャッシュを現在のページのコンテキストに依存させるかどうかを決めます。それゆえ、この設定の効果があるのは、パーシャルとコンポーネントによって使われている場合にかぎられます。 -インクルードされるテンプレートによってパーシャルの出力が異なるとき、パーシャルはコンテキストのなかにある (contextual) と見なされるので、`contextual` 設定を `true` にセットしなければなりません。デフォルトでは、この設定は `false` にセットされており、このことが意味するのは、パーシャルとコンポーネントがどこでインクルードされても出力がつねに同じであるということです。 +インクルードされるテンプレートによってパーシャルの出力が異なるとき、パーシャルはコンテキストのなかにある (contextual) と見なされるので、`contextual` 設定に `true` をセットしなければなりません。デフォルトでは、この設定に `false` がセットされており、このことが意味するのは、パーシャルとコンポーネントがインクルードされる場所がどこであれ、出力はつねに同じであるということです。 >**NOTE** ->パラメータのセットが異なればキャッシュが異なるのは明らかです。 +>パラメータのセットが異なればキャッシュが異なるのはあきらかです。 diff --git a/reference/ja/10-Routing.markdown b/reference/ja/10-Routing.markdown index 17c31a0..3cdbd3d 100644 --- a/reference/ja/10-Routing.markdown +++ b/reference/ja/10-Routing.markdown @@ -1,11 +1,11 @@ routing.yml 設定ファイル -======================= +======================== -`routing.yml` 設定ファイルでは、ルートを定義することができます。 +ルートは `routing.yml` ファイルのなかで定義できます。 -アプリケーションのメイン設定ファイルである `routing.yml` は `apps/APP_NAME/config/` ディレクトリで見つかります。 +アプリケーションの `routing.yml` ファイルは `apps/APP_NAME/config/` ディレクトリに配置されています。 -`routing.yml` 設定ファイルには、名前つきルート定義のリストが用意されています: +`routing.yml` ファイルには、名前つきルート定義のリストが用意されています。 [yml] ROUTE_1: @@ -16,19 +16,19 @@ routing.yml 設定ファイル # ... -リクエストがやってくると、ルーティングシステムはリクエストされた URL がルートとマッチするか試します。最初にマッチするルートが優先されるので、`routing.yml` 設定ファイルで定義されているルートの順序は重要です。 +リクエストがやってくると、ルーティングシステムはリクエストされた URL がルートとマッチするか試します。最初にマッチするルートが優先されるので、`routing.yml` ファイルにおけるルートの記載順は重要です。 -`routing.yml` 設定ファイルが読み込まれるとき、それぞれのルートは `class` クラスのオブジェクトに変換されます: +`routing.yml` ファイルが読み込まれるとき、それぞれのルートは `class` クラスのオブジェクトに変換されます。 [yml] ROUTE_NAME: class: CLASS_NAME # ルートが存在する場合のコンフィギュレーション -`class` クラスは `sfRoute` 基底クラスを継承します。クラスが指定されていなければ、`sfRoute` 基底クラスがフォールバックに使われます。 +`class` クラスは `sfRoute` 基底クラスを継承しなければなりません。クラスが指定されていなければ、`sfRoute` 基底クラスがフォールバックに使われます。 >**NOTE** ->`routing.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は `sfRoutingConfigHandler` [クラス](#chapter_14-Other-Configuration-Files_config_handlers_yml)によって自動管理されます。 +>`routing.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は `sfRoutingConfigHandler` [クラス](#chapter_14-Other-Configuration-Files_config_handlers_yml)にゆだねられます。
@@ -91,33 +91,33 @@ routing.yml 設定ファイル ルートのコンフィギュレーション ------------------------------- -ルートを細かく調整できるようにするために、`routing.yml` 設定ファイルは複数のコンフィギュレーションをサポートします。これらの設定項目は `sfRoutingConfigHandler` クラスによってそれぞれのルートをオブジェクトに変換するのに使われます。 +ルートを細かく調整できるようにするために、`routing.yml` ファイルは複数のコンフィギュレーションをサポートしています。`sfRoutingConfigHandler` クラスによってそれぞれのルートがオブジェクトに変換される際にこれらの設定項目は使われます。 ### ~`class`~ -*デフォルト*: `sfRoute` (もしくは `type` が `collection` である場合 `sfRouteCollection`、下記を参照) +*デフォルト*: `sfRoute` (もしくは `type` に `collection` がセットされている場合は `sfRouteCollection` です。下記の節をご参照ください) -ルートに使われるルートクラスは `class` 設定によって変更できます。 +`class` 設定はルートに使われるルートクラスを指定します。 ### ~`url`~ *デフォルト*: `/` -`url` 設定は現在のリクエストされた URL がマッチしなければならないルートのパターンです。 +`url` 設定はリクエストされた URL に対するパターンマッチに使われるルートのパターンです。 -パターンは複数のセグメント (構成要素) から成り立ちます: +パターンは複数のセグメント (構成要素) からなります。 * 変数 ([コロン `:`](#chapter_05_sub_variable_prefixes) をプレフィックスとする単語) * 定数 * キーと値のペアのシーケンスにマッチするワイルドカード (`*`) -それぞれのセグメントはあらかじめ定義されている区切り文字の1つで区切らなければなりません ([デフォルトは `/` もしくは `.`](#chapter_05_sub_segment_separators))。 +それぞれのセグメントはあらかじめ定義されている区切り文字の1つで区切らなければなりません (デフォルトは `/` もしくは `.`)。 ### ~`params`~ *デフォルト*: 空の配列 -`params` 設定はルートに関連するパラメータの配列を定義します。これらのパラメータは `url` で指定されている変数、もしくはこのルートに関連する変数のデフォルトになります。 +`params` 設定はルートに関連づけられたパラメータの配列を定義します。これらのパラメータは `url` で指定されている変数、もしくはこのルートに関連づけられた変数のデフォルトになります。 ### ~`param`~ @@ -129,30 +129,30 @@ routing.yml 設定ファイル *デフォルト*: 空の配列 -`options` 設定は、ふるまいを細かくカスタマイズするためにルートオブジェクトに渡すオプションの配列です。次の節では、それぞれのルートクラスで利用可能なオプションを説明します。 +`options` 設定はふるまいを細かくカスタマイズするためにルートオブジェクトに渡すオプションの配列です。次の節では、それぞれのルートクラスで利用可能なオプションを説明します。 ### ~`requirements`~ *デフォルト*: 空の配列 -`requirements` 設定は `url` 変数が満たさなければならないルート要件の配列です。キーは `url` 変数で、値はこの変数がマッチしなければならない正規表現です。 +`requirements` 設定は `url` 変数が満たさなければならないルート要件の配列です。キーは `url` 変数で指定され、値はこの変数のパターンマッチに使われる正規表現です。 >**TIP** ->正規表現は別の正規表現に含まれるので、区切り文字で囲んだり、値全体がマッチするようにキャレット (`^`) もしくはドル記号 (`$`) をつける必要はありません。 +>1つの正規表現は別の正規表現に含まれるので、区切り文字で囲んだり、値全体がマッチするようにキャレット (`^`) もしくはドル記号 (`$`) をつける必要はありません。 ### ~`type`~ *デフォルト*: `null` -`type` 設定が `collection` にセットされている場合、ルートはルートコレクションとして読み込まれます。 +`type` 設定に `collection` がセットされている場合、ルートはルートコレクションとして読み込まれます。 >**NOTE** ->`class` の名前に単語の `Collection` が含まれる場合、この設定はコンフィギュレーションハンドラによって自動的に `collection` にセットされます。このことが意味するのは、ほとんどの場合において、この設定を変更する必要がないということです。 +>`class` の名前に単語の `Collection` が含まれる場合、コンフィギュレーションハンドラによってこの設定に `collection` が自動的にセットされます。このことが意味するのは、ほとんどの場合において、この設定を変更する必要はないということです。 ~`sfRoute`~ ----------- -すべてのルートクラスは `sfRoute` 基底クラスを継承します。この基底クラスは必須のルート設定を提供します。 +すべてのルートクラスは `sfRoute` 基底クラスを継承しなければなりません。この基底クラスは必須のルート設定を提供します。 ~`sfRequestRoute`~ ------------------ @@ -161,36 +161,36 @@ routing.yml 設定ファイル *デフォルト*: `get` -`sf_method` オプションは `requirements` 配列に使われます。このオプションによって、ルートのマッチング処理のあいだに HTTP リクエストが強制されます。 +`sf_method` オプションは `requirements` 配列に使われます。このオプションによって、ルートのパターンマッチのあいだに HTTP リクエストが強制されます。 ~`sfObjectRoute`~ ----------------- -`sfObjectRoute` のオプションを指定する場所は `routing.yml` 設定ファイルの `options` 設定の範囲内になければなりません。 +`sfObjectRoute` ルートクラスのオプションを指定する場所は `routing.yml` ファイルの `options` 設定の範囲に入っていなければなりません。 ### ~`model`~ -`model` オプションは必須オプションであり、現在のルートに関連するモデルクラスの名前です。 +`model` オプションは必須オプションであり、現在のルートに関連づけられたモデルクラスの名前です。 ### ~`type`~ -`type` オプションは必須オプションであり、モデルに必要なルートの種類です。このオプションは `object` もしくは `list` のどちらかになります。`object` 型のルートは単独のモデルオブジェクトを表し、`list` 型のルートはモデルオブジェクトのコレクションを表します。 +`type` オプションは必須オプションであり、モデルに必要なルートの種類です。このオプションは `object` もしくは `list` のどちらかになります。`object` 型のルートは単独のモデルオブジェクトをあらわし、`list` 型のルートはモデルオブジェクトのコレクションをあらわします。 ### ~`method`~ -`method` オプションは必須オプションです。このオプションはこのルートに関連するオブジェクトを検索するためにモデルクラスのなかで呼び出すスタティックメソッドです。このメソッドは、呼び出される際にパースされるルートのパラメータを引数にとります。 +`method` オプションは必須オプションです。このオプションはモデルクラスのなかでこのルートに関連づけられたオブジェクトを検索する際に呼び出されるスタティックメソッドです。このメソッドは、パースされたルートのパラメータを引数にとります。 ### ~`allow_empty`~ *デフォルト*: `true` -`allow_empty` オプションが `false` にセットされており、`model` の `method` 呼び出しによってオブジェクトが返されない場合、ルートは404の例外を投げます。 +`allow_empty` オプションに `false` がセットされている場合、`model` の `method` が呼び出された際にオブジェクトが返されなければ、ルートは404エラーの例外を投げます。 ### ~`convert`~ *デフォルト*: `toParams` -`convert` オプションは、モデルオブジェクトにもとづいてルートを生成する際にモデルを適切なパラメータの配列に変換するために呼び出すメソッドです。このメソッドが返す配列には、少なくともルートパターンの必須パラメータが格納されていなければなりません (`url` 設定で定義されます)。 +`convert` オプションは、モデルオブジェクトに応じてルートが生成される場合において、モデルが適切なパラメータの配列に変換される際に呼び出されるメソッドです。このメソッドが返す配列には、少なくともルートパターンの必須パラメータが要素として含まれていなければなりません (`url` 設定で定義されます)。 ~`sfPropelRoute`~ ----------------- @@ -199,7 +199,7 @@ routing.yml 設定ファイル *デフォルト*: コレクションには `doSelect`、単独のオブジェクトには `doSelectOne` -`method_for_criteria` オプションは、現在のリクエストに関連するオブジェクトを検索するためにピアクラスによって呼び出されるメソッドを定義します。このメソッドは、呼び出される際にパースされるルートのパラメータを引数にとります。 +`method_for_criteria` オプションは、現在のリクエストに関連づけされたオブジェクトを検索する際にピアクラスによって呼び出されるメソッドを定義します。このメソッドはパースされたルートのパラメータを引数にとります。 ~`sfDoctrineRoute`~ ------------------- @@ -208,29 +208,29 @@ routing.yml 設定ファイル *デフォルト*: none -`method_for_query` オプションは、現在のリクエストに関連するオブジェクトを検索するときにモデルを呼び出すメソッドを定義します。このメソッドは現在のクエリオブジェクトを引数にとります。 +`method_for_query` オプションは現在のリクエストに関連づけされたオブジェクトを検索する際にモデルを呼び出すメソッドを定義します。このメソッドは現在のクエリオブジェクトを引数にとります。 -このオプションがセットされていない場合、クエリは `execute()` メソッドで「実行」されるだけです。 +このオプションに値がセットされていなければ、`execute()` メソッドによるクエリの「実行」だけがおこなわれます。 ~`sfRouteCollection`~ --------------------- -`sfRouteCollection` 基底クラスはルートのコレクションを表します。 +`sfRouteCollection` 基底クラスはルートのコレクションをあらわします。 ~`sfObjectRouteCollection`~ --------------------------- ### ~`model`~ -`model` オプションは現在のルートに関連するモデルクラスの名前で必須です。 +`model` オプションは現在のルートに関連づけられたモデルクラスの名前で必須です。 ### ~`actions`~ *デフォルト*: `false` -`actions` オプションはルートに許可されるアクションの配列を定義します。アクションは利用可能なすべてのアクションのサブセット (`list`、`new`、`create`、`edit`、`update`、`delete` そして `show`) でなければなりません。 +`actions` オプションはルートに許可されるアクションの配列を定義します。アクションは利用可能なすべてのアクションの部分集合に含まれていなければなりません (`list`、`new`、`create`、`edit`、`update`、`delete` そして `show`)。 -このオプションと `with_show` オプションの両方が `false` にセットされている場合、`show` アクション以外のすべてのアクションが利用可能になります (下記を参照)。 +このオプションと `with_show` オプションの両方に `false` がセットされている場合、`show` アクション以外のすべてのアクションが利用可能になります (下記をご参照ください)。 ### ~`module`~ @@ -240,7 +240,7 @@ routing.yml 設定ファイル ### ~`prefix_path`~ -*デフォルト*: ルートの名前の前につけられる `/` +*デフォルト*: ルートの名前の前につく `/` `prefix_path` オプションはすべての `url` パターンのプレフィックスを指定します。このオプションがとる値は、任意の有効なパターンであり、変数と複数のセグメントです。 @@ -248,25 +248,25 @@ routing.yml 設定ファイル *デフォルト*: `id` -`column` オプションはモデルオブジェクトの一意性を表す識別子として使うモデルのカラムを定義します。 +`column` オプションはモデルオブジェクトの一意性をあらわす識別子に使うモデルのカラムを定義します。 ### ~`with_show`~ *デフォルト*: `true` -`actions` オプションが `false` にセットされている場合でも、ルートに許可されるアクションのリストに `show` アクションを加えるには、`with_show` オプションを使います。 +`with_show` オプションに `true` がセットされていれば、`actions` オプションに `false` がセットされている場合でも、ルートに許可されるアクションのリストに `show` アクションを加えることができます。 ### ~`segment_names`~ *デフォルト*: `array('edit' => 'edit', 'new' => 'new'),` -`segment_names` は `edit` と `new` アクションの `url` パターンで使う単語を定義します。 +`segment_names` オプションは `edit` と `new` アクションの `url` パターンに使われる単語を定義します。 ### ~`model_methods`~ *デフォルト*: 空の配列 -`model_methods` オプションは、モデルからオブジェクトを検索するときに呼び出すメソッドを定義します (`sfObjectRoute` の `method` オプションを参照)。実際には、このオプションは `list` と `object` メソッドを定義する配列です: +`model_methods` オプションはモデルからオブジェクトが検索される際に呼び出されるメソッドを定義します (`sfObjectRoute` ルートクラスの `method` オプションをご参照ください)。実際には、このオプションは `list` と `object` メソッドを定義する配列です。 [yml] model_methods: @@ -283,7 +283,7 @@ routing.yml 設定ファイル *デフォルト*: `false` -`with_wildcard_routes` オプションは、2つのワイルドカードのルート (1つは単独のオブジェクト、もう1つはオブジェクトコレクション) を通してアクションにアクセスできるようにします。 +`with_wildcard_routes` オプションは2つのワイルドカードのルート (1つは単独のオブジェクト、もう1つはオブジェクトコレクション) を通じてアクションにアクセスできるようにします。 ### ~`route_class`~ @@ -295,7 +295,7 @@ routing.yml 設定ファイル *デフォルト*: 空の配列 -`collection_actions` オプションはコレクションルートで利用可能な追加アクションの配列を定義します。キーはアクションの名前で、値はそのアクションに対して有効なメソッドです: +`collection_actions` オプションはコレクションルートで利用可能な追加アクションの配列を定義します。キーはアクションの名前で、値はそのアクションに対して有効なメソッドです。 [yml] articles: @@ -307,7 +307,7 @@ routing.yml 設定ファイル *デフォルト*: 空の配列 -`object_actions` オプションはオブジェクトルートで利用可能な追加アクションの配列を定義します。配列のキーはアクションの名前で値はそのアクションに対して有効なメソッドです: +`object_actions` オプションはオブジェクトルートで利用可能な追加アクションの配列を定義します。配列のキーはアクションの名前で、値はそのアクションに対して有効なメソッドです。 [yml] articles: @@ -318,9 +318,9 @@ routing.yml 設定ファイル ~`sfPropelRouteCollection`~ --------------------------- -`sfPropelRouteCollection` ルートクラスは `sfRouteCollection` を継承し、デフォルトのルートクラスを `sfPropelRoute` に変更します (上記の `route_class` オプションを参照)。 +`sfPropelRouteCollection` ルートクラスは `sfRouteCollection` 基底クラスを継承し、デフォルトのルートクラスを `sfPropelRoute` に変更します (上記の `route_class` オプションをご参照ください)。 ~`sfDoctrineRouteCollection`~ ----------------------------- -`sfDoctrineRouteCollection` ルートクラスは `sfRouteCollection` を継承し、デフォルトのルートクラスを `sfDoctrineRoute` に変更します (上記の `route_class` オプションを参照)。 +`sfDoctrineRouteCollection` ルートクラスは `sfRouteCollection` 基底クラスを継承し、デフォルトのルートクラスを `sfDoctrineRoute` に変更します (上記の `route_class` オプションをご参照ください)。 diff --git a/reference/ja/11-App.markdown b/reference/ja/11-App.markdown index b37a751..0a54e5b 100644 --- a/reference/ja/11-App.markdown +++ b/reference/ja/11-App.markdown @@ -1,23 +1,23 @@ app.yml 設定ファイル ==================== -アプリケーション固有の設定を変更できるようにするために、symfony フレームワークは組み込みの `app.yml` 設定ファイルを提供します。 +特定のアプリケーション固有の設定を変更できるようにするために、組み込みの `app.yml` ファイルが用意されています。 -`app.yml` 設定ファイルでは、特定のアプリケーションで使いたい任意の設定を定義することができます。コードにおいて、これらの設定項目はグローバルな `sfConfig` クラスを通して利用可能で、キーにはプレフィックスの `app_` がつきます: +`app.yml` ファイルでは、特定のアプリケーションで使いたい任意の設定を定義することができます。コードにおいて、これらの設定項目はグローバルな `sfConfig` クラスを通じて利用可能で、キーにプレフィックスの `app_` がつきます。 [php] sfConfig::get('app_active_days'); -`sfConfig` クラスが [symfony の設定](#chapter_03)と[プロジェクトのディレクトリ](#chapter_03)にアクセスする権限を提供するので、区別できるように、すべての設定の名前にはプレフィックスの `app_` がつきます。 +`sfConfig` クラスが [symfony の設定](#chapter_03)と[プロジェクトのディレクトリ](#chapter_03)にアクセスする権限を提供するので、これらを区別できるようにするために、すべての設定の名前にプレフィックスの `app_` がつきます。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`app.yml` ファイルでは、**環境が認識され**、**コンフィギュレーションカスケードのメカニズム**がはたらきます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`app.yml` ファイルでは、**環境**が認識され、**コンフィギュレーションカスケード**のメカニズムがはたらいています。 -`app.yml` 設定ファイルは環境に合わせて変化する設定 (たとえば API キー) もしくは長期にわたって変更される設定 (たとえばメールアドレス) を定義するのにふさわしい場所です。このファイルは symfony もしくは PHP をかならずしも理解する必要のないひと (たとえばシステム管理者) が変更する必要のある設定を定義するのにも最適な場所です。 +`app.yml` ファイルは環境に応じて変化する設定 (たとえば API キー) もしくは長期にわたって変更される設定 (たとえばメールアドレス) を定義するのに最適な場所です。このファイルは symfony もしくは PHP をかならずしも理解する必要のない人 (たとえばシステム管理者) が変更する必要のある設定を定義するのにも適切な場所です。 >**TIP** ->アプリケーションのロジックをまとめるために `app.yml` を使うのはお控えください。 +>アプリケーションのロジックをまとめるために `app.yml` ファイルを使うことはお控えください。 - >**NOTE** ->`app.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfDefineEnvironmentConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`app.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfDefineEnvironmentConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 diff --git a/reference/ja/12-Filters.markdown b/reference/ja/12-Filters.markdown index 78cca94..4e5f1e8 100644 --- a/reference/ja/12-Filters.markdown +++ b/reference/ja/12-Filters.markdown @@ -1,13 +1,13 @@ filters.yml 設定ファイル ======================== -~`filters.yml`~ 設定ファイルでは、すべてのリクエストで実行されるフィルタチェーンを記述します。 +すべてのリクエストで実行されるフィルタチェーンは ~`filters.yml`~ ファイルに記述します。 -アプリケーションのメイン設定ファイルである `filters.yml` は `apps/APP_NAME/config/` ディレクトリで見つかります。 +アプリケーションの `filters.yml` ファイルは `apps/APP_NAME/config/` ディレクトリに配置されています。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`filters.yml` ファイルでは、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`filters.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 -`filters.yml` 設定ファイルには名前つきフィルタ定義のリストが用意されています: +名前つきフィルタの定義リストが `filters.yml` ファイルに用意されています。 [yml] FILTER_1: @@ -18,25 +18,25 @@ filters.yml 設定ファイル # ... -コントローラがリクエストに対応してフィルタチェーンを初期化するとき、`filters.yml` ファイルを読み込み、フィルタオブジェクトを設定するために使われるフィルタのクラス名 (`class`) とパラメータ (`param`) を探し、フィルタを登録します: +コントローラがリクエストに応じてフィルタチェーンを初期化するとき、`filters.yml` ファイルが読み込まれ、フィルタのクラス名 (`class`) とフィルタオブジェクトを初期化する際に使われるパラメータ (`param`) が探索され、フィルタが登録されます。 [yml] FILTER_NAME: class: CLASS_NAME param: { ARRAY OF PARAMETERS } -フィルタは設定ファイルに記載されている順序で実行されます。symfony は複数のフィルタを1つのチェーンとして実行するので、最初に登録されるフィルタは最初と最後に実行されます。 +フィルタは設定ファイルで定義されている順番で実行されます。複数のフィルタは1つのチェーンとして実行されるので、最初に登録されるフィルタは最初と最後に実行されます。 -`class` クラスは `sfFilter` 基底クラスを継承します。 +`class` クラスは `sfFilter` 基底クラスを継承しなければなりません。 -フィルタクラスがオートロードされない場合、`file` パスが定義され、フィルタオブジェクトが作られる前に自動的にインクルードされます: +フィルタクラスがオートロードされていなければ、`file` パスが定義され、フィルタオブジェクトが作られる前に自動的にインクルードされます。 [yml] FACTORY_NAME: class: CLASS_NAME file: ABSOLUTE_PATH_TO_FILE -`filters.yml` ファイルをオーバーライドするとき、継承するファイルからすべてのフィルタを守らなければなりません: +`filters.yml` ファイルをオーバーライドする場合、継承するファイルからすべてのフィルタを守らなければなりません。 [yml] rendering: ~ @@ -44,13 +44,13 @@ filters.yml 設定ファイル cache: ~ execution: ~ -フィルタを除外するには、`enabled` キーを `false` にセットして無効にする必要があります: +フィルタを除外するには、`enabled` キーに `false` をセットして無効にする必要があります。 [yml] FACTORY_NAME: enabled: false -特別な名前のフィルタが2つあります (`rendering` と `execution`)。これらのフィルタは両方とも必須で、`type` パラメータで指定します。最初に登録されるのはつねに `rendering` フィルタで、最後に登録されるのは `execution` フィルタです: +特殊なフィルタが2つ用意されています (`rendering` と `execution`)。これらのフィルタは両方とも必須で、`type` パラメータで指定します。最初に登録されるのはつねに `rendering` フィルタで、最後に登録されるのは `execution` フィルタです。 [yml] rendering: @@ -66,7 +66,7 @@ filters.yml 設定ファイル type: execution >**NOTE** ->`filters.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfFilterConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`filters.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfFilterConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。
@@ -89,7 +89,7 @@ filters.yml 設定ファイル param: type: rendering -`rendering` フィルタはブラウザへのレスポンス出力の責務を担います。このフィルタは最初に登録されるフィルタであり、リクエストを管理する機会をもつ最後のフィルタでもあります。 +`rendering` フィルタはブラウザへのレスポンス出力を受け持ちます。このフィルタは最初に登録されるフィルタであり、リクエストを操作する機会をもつ最後のフィルタでもあります。 `security` ---------- @@ -102,14 +102,14 @@ filters.yml 設定ファイル param: type: security -`security` フィルタは、アクションの `getCredential()` メソッドを呼び出すことでセキュリティをチェックします。いったんクレデンシャルを得られたら、ユーザーオブジェクトの `hasCredential()` メソッドを呼び出すことで、ユーザーが同じクレデンシャルをもつことを確認できます。 +`security` フィルタはアクションの `getCredential()` メソッドを呼び出してセキュリティをチェックします。いったんクレデンシャルを得られたら、ユーザーオブジェクトの `hasCredential()` メソッドを呼び出して、ユーザーが同じクレデンシャルをもっていることを確認できます。 `security` フィルタのデータ型は `security` でなければなりません。 -`security` フィルタのコンフィギュレーションをきめ細かく調整するには、`security.yml` 設定[ファイル](#chapter_08)を通して行います。 +`security` フィルタのコンフィギュレーションをきめ細かく調整する場所は `security.yml` [ファイル](#chapter_08)です。 >**TIP** ->`security.yml` で必須のアクションがセキュアなものとして設定されていない場合、`security` フィルタは実行されません。 +>`security.yml` ファイルのなかで必須のアクションにアクセス制限がかけられていない場合、`security` フィルタは実行されません。 `cache` ------- @@ -122,7 +122,7 @@ filters.yml 設定ファイル param: condition: %SF_CACHE% -`cache` フィルタはアクションとページを管理します。このフィルタは必要な HTTP キャッシュヘッダーをレスポンスに追加するための責務も担います (`Last-Modified`、`ETag`、`Cache-Control`、`Expires`、・・・)。 +`cache` フィルタはアクションとページを管理します。このフィルタは必要な HTTP キャッシュヘッダーをレスポンスに追加する仕事も受け持ちます (`Last-Modified`、`ETag`、`Cache-Control`、`Expires`、・・・)。 `execution` ----------- diff --git a/reference/ja/13-View.markdown b/reference/ja/13-View.markdown index ad8b0b0..b1e18ae 100644 --- a/reference/ja/13-View.markdown +++ b/reference/ja/13-View.markdown @@ -1,14 +1,14 @@ view.yml 設定ファイル -==================== +===================== -ビューレイヤーのコンフィギュレーションは `view.yml` 設定ファイルを編集することで変更できます。 +ビューレイヤーのコンフィギュレーションは `view.yml` ファイルのなかで変更できます。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`view.yml` ファイルでは、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`view.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 >**CAUTION** ->ほとんどの場合、アクションから呼び出されるテンプレートもしくはメソッドで直接使われるヘルパーを尊重するため、この設定ファイルの変更は推奨されません。 +>アクションから呼び出されるテンプレートもしくはメソッドによって直接使われるヘルパーのほうが望ましいので、この設定ファイルの変更は推奨されていません。 -`view.yml` 設定ファイルには、ビュー設定のリストが用意されています: +ビュー設定のリストは `view.yml` ファイルに用意されています。 [yml] VIEW_NAME_1: @@ -20,7 +20,7 @@ view.yml 設定ファイル # ... >**NOTE** ->`view.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は `sfViewConfigHandler` [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`view.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は `sfViewConfigHandler` [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 `layout` -------- @@ -32,10 +32,10 @@ view.yml 設定ファイル has_layout: true layout: layout -`view.yml` 設定ファイルでは、アプリケーションによって使われるデフォルトの ~`layout`~ を定義します。デフォルトでは、名前は `layout` で、symfony はアプリケーションの `templates/` ディレクトリに設置されている `layout.php` ファイルによってすべてのページを飾りつけます。~`has_layout`~ エントリを `false` にセットすることで、飾りつけ処理を完全に無効にすることもできます。 +アプリケーションによって使われるデフォルトの ~`layout`~ は `view.yml` ファイルのなかで定義されます。デフォルトの名前は `layout` で、すべてのページはアプリケーションの `templates/` ディレクトリに配置されている `layout.php` ファイルによってデコレートされます。~`has_layout`~ エントリに `false` をセットすれば、デコレーション処理を完全に無効にすることもできます。 >**TIP** ->`view` に対して明示的にセットされていないかぎり、`layout` は XML、HTTP リクエストと HTML ではない Content-Type に対して自動的に無効になります。 +>`view` に対して `layout` が明確にセットされていないかぎり、XML、HTTP リクエストおよび HTML ではない Content-Type に対して自動的に無効になります。 `stylesheets` ------------- @@ -46,28 +46,28 @@ view.yml 設定ファイル default: stylesheets: [main.css] -`stylesheets` エントリは現在のビューで使うスタイルシートの配列を定義します。 +`stylesheets` エントリは現在のビューで使われるスタイルシートの配列を定義します。 >**NOTE** ->`view.yml` で定義されているスタイルシートを手動でインクルードするには、`include_stylesheets()` ヘルパーを使います。 +>`include_stylesheets()` ヘルパーを使えば、`view.yml` ファイルで定義されているスタイルシートを手動でインクルードできます。 -複数のファイルが定義されている場合、symfony はこれらのファイルを定義と同じ順序でインクルードします: +複数のファイルが定義されている場合、定義と同じ順番でインクルードされます。 [yml] stylesheets: [main.css, foo.css, bar.css] -`media` 属性を変更もしくは `.css` 拡張子を省略することもできます: +`media` 属性を変更もしくは `.css` 拡張子を省略することもできます。 [yml] stylesheets: [main, foo.css, bar.css, print.css: { media: print }] -`use_stylesheet()` ヘルパーを尊重するために、この設定は*推奨されません*: +`use_stylesheet()` ヘルパーを使うやりかたのほうが望ましいので、この設定を変更することは*推奨されていません*。 [php] >**NOTE** ->デフォルトの `view.yml` 設定ファイルでは、参照されるファイルは `main.css` であり `/css/main.css` ではありません。実際のところ、symfony は相対パスの前に `/css/` をつけるので、両方の定義は同じです。 +>デフォルトの `view.yml` ファイルでは、参照されるファイルは `main.css` であり `/css/main.css` ではありません。実際のところ、symfony は相対パスの前に `/css/` をつけるので、両方の定義は同じです。 `javascripts` ------------- @@ -81,25 +81,25 @@ view.yml 設定ファイル `javascripts` エントリは現在のビューに使う JavaScript ファイルの配列を定義します。 >**NOTE** ->`view.yml` で定義されている JavaScript ファイルを手動でインクルードするには、`include_javascripts()` ヘルパーを使います。 +>`view.yml` 設定ファイルで定義されている JavaScript ファイルを手動でインクルードするには、`include_javascripts()` ヘルパーを使います。 -複数のファイルが定義されている場合、symfony は定義と同じ順序でこれらのファイルをインクルードします: +複数のファイルが定義されている場合、定義と同じ順番でこれらのファイルがインクルードされます。 [yml] javascripts: [foo.js, bar.js] -`.js` 拡張子を省略することもできます: +`.js` 拡張子を省略することもできます。 [yml] javascripts: [foo, bar] -`use_javascript()` ヘルパーを尊重するために、この設定は*推奨されません*: +`use_javascript()` ヘルパーを使うやりかたのほうが望ましいので、この設定を変更することは*推奨されていません*。 [php] >**NOTE** ->`foo.js` のような相対パスを使うとき、symfony はこれらのパスの前に `/js/` をつけます。 +>`foo.js` のような相対パスを使うと、パスの前に `/js/` がつきます。 `metas` と `http_metas` ----------------------- @@ -121,9 +121,9 @@ view.yml 設定ファイル レイアウトのなかでインクルードするメタタグは `http_metas` と `metas` 設定によって定義できます。 >**NOTE** ->`view.yml` で定義されているメタタグを手動でインクルードするには、`include_metas()` と `include_http_metas()` ヘルパーを使います。 +>`view.yml` ファイルで定義されているメタタグを手動でインクルードするには、`include_metas()` と `include_http_metas()` ヘルパーを使います。 -静的なメタ情報 (Content-Type など) のためのレイアウトのなかで HTML を純粋に保つため、もしくは動的なメタ情報 (タイトルや説明) のスロットを尊重するためにこれらの設定は*非推奨*です。 +変化しないメタ情報 (Content-Type など) のためにレイアウトのなかで HTML を純粋に保つため、もしくは動的なメタ情報 (タイトルや説明) のスロットのほうが望ましいので、これらの設定は*推奨されていません*。 >**TIP** ->設定が反映されるとき、[`settings.yml` 設定ファイル](#chapter_04_sub_charset)で定義されている文字集合をインクルードするために、HTTP の `Content-Type` のメタ情報は自動的に修正されます。 +>設定が反映されるとき、[`settings.yml` ファイル](#chapter_04_sub_charset)で定義されている文字集合をインクルードするために、`Content-Type` ヘッダーのメタ情報は自動的に修正されます。 diff --git a/reference/ja/14-Other-Configuration-Files.markdown b/reference/ja/14-Other-Configuration-Files.markdown index fd4135a..3bc3979 100644 --- a/reference/ja/14-Other-Configuration-Files.markdown +++ b/reference/ja/14-Other-Configuration-Files.markdown @@ -1,19 +1,19 @@ その他の設定ファイル -====================== +===================== -この章では、symfony のその他の設定ファイルを説明します。これらを変更する必要性はほとんどありません。 +この章では、その他の設定ファイルを説明します。これらを変更することはほとんどありません。 ~`autoload.yml`~ ---------------- -`autoload.yml` 設定ファイルでは、オートロードされる必要のあるディレクトリが決まります。PHP クラスとインターフェイスを見つけるためにそれぞれのディレクトリがスキャンされます。 +オートロードの対象となるディレクトリは `autoload.yml` ファイルのなかで指定できます。PHP クラスとインターフェイスを捜索するために、それぞれのディレクトリがスキャンされます。 -[設定ファイルの原則の章](#chapter_03)で説明したように、`autoload.yml` ファイルでは、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`autoload.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 >**NOTE** ->`autoload.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。 +>`autoload.yml` ファイルのキャッシュは PHP ファイルとして保存されます。 -ほとんどのプロジェクトでは、デフォルトのコンフィギュレーションで十分です: +ほとんどのプロジェクトでは、デフォルトのコンフィギュレーションで事足ります。 [yml] autoload: @@ -41,22 +41,22 @@ prefix: 1 recursive: true -それぞれのコンフィギュレーションは名前をもち、その名前をもつキーの下でセットしなければなりません。このことによって、デフォルトのコンフィギュレーションをオーバーライドできます。 +それぞれのコンフィギュレーションに名前をつけ、その名前と同じキーの下側でコンフィギュレーションの内容を記述しなければなりません。これらの作業をおこなうことで、デフォルトのコンフィギュレーションをオーバーライドできます。 >**TIP** ->ご覧のとおり、デフォルトでは、`lib/vendor/symfony/` ディレクトリは除外されます。symfony はコアクラスに対して異なるオートロードメカニズムを利用するからです。 +>ご覧のとおり、デフォルトでは、`lib/vendor/symfony/` ディレクトリは除外されています。コアクラスに対して異なるオートロードメカニズムがはたらいているからです。 -オートロードのふるまいをカスタマイズするために、いくつかのキーを使うことができます: +オートロードのふるまいをカスタマイズするには、次のキーを使います。 * `name`: 説明 - * `path`: オートロードするパス + * `path`: オートロードの対象となるパス * `recursive`: サブディレクトリで PHP クラスを探索するか - * `exclude`: 検索から除外するディレクトリの名前の配列 - * `prefix`: 指定モジュールのために、パスで見つかるクラスだけをオートロードの対象にする場合 `true` にセットします (デフォルトは `false`) - * `files`: PHP クラスのために明示的にパースするファイルの配列 + * `exclude`: 検索の対象から除外するディレクトリの名前の配列 + * `prefix`: 指定したモジュールのために、オートロードの対象になるクラスをパスで見つかるものに限定する場合、`true` をセットします (デフォルトは `false`) + * `files`: PHP クラスのためにパースされるファイルの配列 * `ext`: PHP クラスの拡張子 (デフォルトは `.php`) -たとえば、オートロードをサポートする大きなライブラリをプロジェクトの `lib/` ディレクトリに組み込む場合、パフォーマンスを向上させるには、`project` のオートロードコンフィギュレーションを修正して、symfony のデフォルトのオートロードシステムの対象からこのライブラリを除外します: +たとえば、オートロード機能をサポートしている大きなライブラリをプロジェクトの `lib/` ディレクトリに組み込む場合、パフォーマンスを向上させるために、`project` のオートロードコンフィギュレーションを修正して、このライブラリをオートロードの対象から外すことができます。 [yml] autoload: @@ -69,7 +69,7 @@ ~`config_handlers.yml`~ ----------------------- -`config_handlers.yml` 設定ファイルでは、ほかのすべての YAML 設定ファイルを解釈するために使われるコンフィギュレーションハンドラクラスを記入します。`settings.yml` 設定ファイルをロードするために使われるデフォルトコンフィギュレーションは次のとおりです: +ほかのすべての YAML ファイルのパースに使われるコンフィギュレーションハンドラクラスは `config_handlers.yml` ファイルに登録します。`settings.yml` ファイルのロードに使われるデフォルトのコンフィギュレーションは次のようになります。 [yml] config/settings.yml: @@ -77,11 +77,14 @@ param: prefix: sf_ -それぞれの設定ファイルはクラス (`class` エントリ) によって定義され、`param` セクションの下でパラメータを定義することで、細かくカスタマイズできます。 +それぞれの設定ファイルはクラス (`class` エントリ) によって定義され、`param` セクションのなかでパラメータを定義することで、細かくカスタマイズできます。 -デフォルトの `config_handlers.yml` ファイルは次のようなパーサークラスを定義します: +>**TIP** +>自前のコンフィギュレーションハンドラを追加するとき、ハンドラのソースファイルに設けられている `class` と `file` エントリの下側でクラスの名前とフルパスをそれぞれ指定しなけばなりません。`sfApplicationConfiguration` クラスのなかでメカニズムを有効にする前にコンフィギュレーションを初期化する必要があるからです。 + +`config_handlers.yml` ファイルでは、次のようなデフォルトのパーサークラスが定義されています。 - | 設定ファイル | コンフィグハンドラクラス | + | 設定ファイル | コンフィグハンドラクラス | | ------------------ | ---------------------------------- | | `autoload.yml` | `sfAutoloadConfigHandler` | | `databases.yml` | `sfDatabaseConfigHandler` | @@ -100,7 +103,7 @@ ~`core_compile.yml`~ -------------------- -`core_compile.yml` 設定ファイルでは、symfony のロード時間を短縮するために `prod` 環境で1つの大きなファイルにマージされる PHP ファイルを記入します。デフォルトでは、symfony のメインのコアクラスが定義されます。アプリケーションがリクエストごとにロードする必要のある複数のクラスに依存する場合、プロジェクトもしくはアプリケーションの `core_compile.yml` 設定ファイルを用意すれば、これらのクラスを設定ファイルに追加できます。デフォルトコンフィギュレーションの抜粋は次のとおりです: +symfony のロード時間を短縮するために、`prod` 環境において1つの大きなファイルにマージされる PHP ファイルの名前は `core_compile.yml` ファイルに登録できます。デフォルトでは、symfony コアの主要なクラスが登録されています。アプリケーションがリクエストごとにロードする必要のある複数のクラスに依存している場合、プロジェクトもしくはアプリケーションの `core_compile.yml` ファイルを配置すれば、これらのクラスをマージの対象に追加できます。次のコードはデフォルトのコンフィギュレーションの内容を抜粋したものです。 [yml] - %SF_SYMFONY_LIB_DIR%/autoload/sfAutoload.class.php @@ -108,17 +111,17 @@ - %SF_SYMFONY_LIB_DIR%/action/sfAction.class.php - %SF_SYMFONY_LIB_DIR%/action/sfActions.class.php -[設定ファイルの原則の章](#chapter_03)で説明したように、`core_compile.yml` ファイルでは、**コンフィギュレーションカスケードのメカニズム**がはたらき、**定数**を定義することができます。 +[設定ファイルの原則の章](#chapter_03)で述べたように、`core_compile.yml` ファイルでは、**コンフィギュレーションカスケード**のメカニズムがはたらいており、**定数**を定義することができます。 >**NOTE** ->`core_compile.yml` 設定ファイルは PHP ファイルとしてキャッシュされます。処理は ~`sfCompileConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)によって自動管理されます。 +>`core_compile.yml` ファイルのキャッシュは PHP ファイルとして保存されます。処理は ~`sfCompileConfigHandler`~ [クラス](#chapter_14_config_handlers_yml)にゆだねられます。 ~`module.yml`~ -------------- -`module.yml` 設定ファイルではモジュールのコンフィギュレーションを変更できます。この設定ファイルが変更されることはほとんどなく、下記の定義済みのエントリだけが用意されています。 +モジュールのコンフィギュレーションを変更する場所は `module.yml` ファイルです。この設定ファイルを変更することはほとんどなく、下記の定義ずみのエントリが用意されています。 -`module.yml` ファイルは symfony によってロードされるモジュールの `config/` サブディレクトリに保存されます。次のコードはすべての設定のデフォルトが用意されている `module.yml` の典型的な内容を示しています: +`module.yml` ファイルはモジュールの `config/` サブディレクトリに配置されています。次のコードは `module.yml` ファイルの典型的な内容で、すべての設定のデフォルトが用意されています。 [yml] all: @@ -126,8 +129,8 @@ view_class: sfPHP partial_view_class: sf -`enabled` パラメータが `false` にセットされている場合、モジュールのすべてのアクションは無効になります。これらのアクションへのリクエストは ([`settings.yml`](#chapter_04) で定義されている) [~`module_disabled_module`~](#chapter_04)/~`module_disabled_action`~ アクションにリダイレクトされます。 +`enabled` パラメータに `false` をセットすれば、モジュールのアクションはすべて無効になります。これらのアクションへのリクエストは ([`settings.yml`](#chapter_04) ファイルで定義されている) [~`module_disabled_module`~](#chapter_04)/~`module_disabled_action`~ アクションにリダイレクトされます。 -`view_class` パラメータは、モジュールのすべてのアクションによって使われ、`sfView` を継承するビュークラスを定義します (サフィックスの `View` はつけません)。 +`view_class` パラメータは `sfView` 基底クラスを継承するビュークラスを定義します (サフィックスの `View` はつきません)。このクラスはモジュールのすべてのアクションによって使われます。 -`partial_view_class` パラメータは、このモジュールのパーシャルに使われ、`sfPartialView` を継承するビュークラスを定義します (サフィックスの `PartialView` はつけません)。 +`partial_view_class` パラメータは `sfPartialView` クラスを継承するビュークラスを定義します (サフィックスの `PartialView` はつきません)。このクラスはモジュールのパーシャルによって使われます。 diff --git a/reference/ja/15-Events.markdown b/reference/ja/15-Events.markdown index d8172fc..be667eb 100644 --- a/reference/ja/15-Events.markdown +++ b/reference/ja/15-Events.markdown @@ -1,60 +1,60 @@ イベント ======== -`sfEventDispatcher` オブジェクトのおかげで、symfony のコアコンポーネントは疎結合されています。Event Dispatcher はコアコンポーネントのあいだのコミュニケーションを管理します。 +symfony のコアコンポーネントは `sfEventDispatcher` オブジェクトによって疎結合されています。イベントディスパッチャ (Event Dispatcher) はコアコンポーネントのあいだのコミュニケーションを司ります。 -あるオブジェクトがディスパッチャにイベントを通知すれば、ほかのオブジェクトは、ディスパッチャに接続していることで (つながっていることで)、特定のイベントをリスニングできます。 +あるオブジェクトがディスパッチャにイベントを通知すれば、ディスパッチャに接続しているほかのオブジェクトがそのイベントをリスニングできるようになります。 -イベントは単なる名前で、ドット (`.`) で区切られる名前空間と名前で構成されます。 +イベントは単なる名前で、ドット (`.`) で区切られた名前空間と名前からなります。 -使い方 +使いかた ------ -最初にイベントオブジェクトを作ります: +最初にイベントオブジェクトを作ります。 [php] $event = new sfEvent($this, 'user.change_culture', array('culture' => $culture)); -そしてディスパッチャにイベントを通知させます: +そしてディスパッチャにイベントを通知させます。 $dispatcher->notify($event); -`sfEvent` コンストラクタは3つの引数をとります: +`sfEvent` コンストラクタは3つの引数をとります。 * イベントの「サブジェクト (対象)」 (ほとんどの場合、これはイベントを通知するオブジェクトになりますが、`null` にもなります) * イベントの名前 * リスナーに渡すパラメータの配列 -リスナーにイベントをリスニングさせるために、リスナーをディスパッチャに接続させます (つなげます): +リスナーがイベントをリスニングできるようにするために、リスナーをディスパッチャに接続させます。 [php] $dispatcher->connect('user.change_culture', array($this, 'listenToChangeCultureEvent')); -ディスパッチャの `connect` メソッドは2つの引数をとります: +ディスパッチャの `connect` メソッドは2つの引数をとります。 * イベントの名前 * イベントが通知されるときに呼び出される関数/メソッド -リスナーの実装例は次のとおりです: +リスナーの実装例は次のようになります。 [php] public function listenToChangeCultureEvent(sfEvent $event) { - // メッセージフォーマットオブジェクトを新しいカルチャで変更する + // メッセージフォーマットオブジェクトを新しいカルチャで変更します $this->setCulture($event['culture']); } -リスナーはイベントを第1引数にとります。イベントオブジェクトはイベント情報を提供するためのメソッドをいくつかもちます: +リスナーはイベントを第1引数にとります。イベントオブジェクトにはイベント情報を提供するためのメソッドがいくつか備わっています。 * `getSubject()`: イベントにアタッチされているサブジェクトオブジェクトを取得します。 * `getParameters()`: イベントパラメータを返します。 -イベントオブジェクトには配列形式としてもアクセスできます。 +配列方式によるイベントオブジェクトへのアクセス方法も用意されています。 イベントの種類 -------------- -イベントは3つの異なるメソッドによって発生します: +イベントは3つの異なるメソッドによって作られます。 * `notify()` * `notifyUntil()` @@ -62,15 +62,15 @@ ### ~`notify`~ -`notify()` メソッドはすべてのリスナーに通知します。リスナーは値を返すことはできません。すべてのリスナーの実行は保証されます。 +`notify()` メソッドはすべてのリスナーに通知します。リスナーは値を返すことはできません。すべてのリスナーの実行は保証されています。 ### ~`notifyUntil`~ -1つのリスナーが `true` の値を返して、チェーンを止めるまで、`notifyUntil()` メソッドはすべてのリスナーに通知し続けます。 +1つのリスナーが `true` の値を返されることで、チェーンが止まるまで、`notifyUntil()` メソッドはすべてのリスナーに通知しつづけます。 チェーンを止めるリスナーは `setReturnValue()` メソッドを呼び出すこともできます。 -通知オブジェクトは、`isProcessed()` メソッドを呼び出すことで、リスナーが処理済みのイベントをもっているかチェックできます: +リスナーが処理ずみのイベントをもっていることをチェックするには、通知オブジェクトのなかで `isProcessed()` メソッドを呼び出します。 [php] if ($event->isProcessed()) @@ -80,9 +80,9 @@ ### ~`filter`~ -`filter()` メソッドは、通知オブジェクトによって第2引数に渡される任意の値をフィルタリングし、リスナーの第2引数に渡される関数/メソッドによって結果が読み出されることを通知します。すべてのリスナーは受け取った値をフィルタリングして返さなければなりません。すべてのリスナーの実行は保証されます。 +`filter()` メソッドは、通知オブジェクトから第2引数に渡される任意の値にフィルタをかけ、リスナーの第2引数に渡される関数/メソッドによって結果がとり出されたことを通知します。すべてのリスナーは受けとった値にフィルタをかけて返さなければなりません。すべてのリスナーの実行は保証されています。 -通知オブジェクトは `getReturnValue()` メソッドを呼び出すことで、フィルタリング済みの値を得ることができます: +通知オブジェクトは `getReturnValue()` メソッドを呼び出すことで、フィルタ処理ずみの値を得ることができます。 [php] $ret = $event->getReturnValue(); @@ -94,6 +94,7 @@ * [`application`](#chapter_15_application) * [`application.log`](#chapter_15_sub_application_log) + * [`application.throw_exception`](#chapter_15_sub_application_throw_exception) * [`command`](#chapter_15_command) * [`command.log`](#chapter_15_sub_command_log) * [`command.pre_command`](#chapter_15_sub_command_pre_command) @@ -105,20 +106,43 @@ * [`component.method_not_found`](#chapter_15_sub_component_method_not_found) * [`context`](#chapter_15_context) * [`context.load_factories`](#chapter_15_sub_context_load_factories) + * [`context.method_not_found`](#chapter_15_sub_context_method_not_found) * [`controller`](#chapter_15_controller) * [`controller.change_action`](#chapter_15_sub_controller_change_action) * [`controller.method_not_found`](#chapter_15_sub_controller_method_not_found) * [`controller.page_not_found`](#chapter_15_sub_controller_page_not_found) + * [`debug`](#chapter_15_debug) + * [`debug.web.load_panels`](#chapter_15_sub_debug_view_load_panels) + * [`debug.web.view.filter_parameter_html`](#chapter_15_sub_debug_web_view_filter_parameter_html) + * [`doctrine`](#chapter_15_doctrine) + * [`doctrine.configure`](#chapter_15_sub_doctrine_configure) + * [`doctrine.filter_model_builder_options`](#chapter_15_sub_doctrine_filter_model_builder_options) + * [`doctrine.filter_cli_config`](#chapter_15_sub_doctrine_filter_cli_config) + * [`doctrine.configure_connection`](#chapter_15_sub_doctrine_configure_connection) + * [`doctrine.admin.delete_object`](#chapter_15_sub_doctrine_delete_object) + * [`doctrine.admin.save_object`](#chapter_15_sub_doctrine_save_object) + * [`doctrine.admin.build_query`](#chapter_15_sub_doctrine_build_query) + * [`doctrine.admin.pre_execute`](#chapter_15_sub_doctrine_pre_execute) * [`form`](#chapter_15_form) * [`form.post_configure`](#chapter_15_sub_form_post_configure) * [`form.filter_values`](#chapter_15_sub_form_filter_values) * [`form.validation_error`](#chapter_15_sub_form_validation_error) * [`form.method_not_found`](#chapter_15_sub_form_method_not_found) + * [`mailer`](#chapter_15_mailer) + * [`mailer.configure`](#chapter_15_sub_mailer_configure) * [`plugin`](#chapter_15_plugin) * [`plugin.pre_install`](#chapter_15_sub_plugin_pre_install) * [`plugin.post_install`](#chapter_15_sub_plugin_post_install) * [`plugin.pre_uninstall`](#chapter_15_sub_plugin_pre_uninstall) * [`plugin.post_uninstall`](#chapter_15_sub_plugin_post_uninstall) + * [`propel`](#chapter_15_propel) + * [`propel.configure`](#chapter_15_sub_propel_configure) + * [`propel.filter_phing_args`](#chapter_15_sub_propel_filter_phing_args) + * [`propel.filter_connection_config`](#chapter_15_sub_propel_filter_connection_config) + * [`propel.admin.delete_object`](#chapter_15_sub_propel_admin_delete_object) + * [`propel.admin.save_object`](#chapter_15_sub_propel_admin_save_object) + * [`propel.admin.build_criteria`](#chapter_15_sub_propel_admin_build_criteria) + * [`propel.admin.pre_execute`](#chapter_15_sub_propel_admin_pre_execute) * [`request`](#chapter_15_request) * [`request.filter_parameters`](#chapter_15_sub_request_filter_parameters) * [`request.method_not_found`](#chapter_15_sub_request_method_not_found) @@ -150,13 +174,13 @@ *通知メソッド*: `notify` -*デフォルトの通知オブジェクト*: たくさんのクラス +*デフォルトの通知オブジェクト*: さまざまなクラス | パラメータ | 説明 | ------------ | ---------------------------------------------------------------------------------- | `priority` | 優先順位 (`sfLogger::EMERG`、`sfLogger::ALERT`、`sfLogger::CRIT`、`sfLogger::ERR`、 `sfLogger::WARNING`、`sfLogger::NOTICE`、`sfLogger::INFO` もしくは `sfLogger::DEBUG`) -`application.log` イベントは、HTTP リクエストのロギングをするために symfony によって利用されるメカニズムです (logger ファクトリを参照)。このイベントは symfony のコアコンポーネントの大半によって通知されます。 +`application.log` イベントは HTTP リクエストのロギングシステムに利用されています (logger ファクトリをご参照ください)。さまざまな symfony のコアコンポーネントがこのイベントを通知します。 ### ~`application.throw_exception`~ @@ -164,9 +188,9 @@ *デフォルトの通知オブジェクト*: `sfException` -リクエスト処理のあいだに捕まらない例外が投げられるとき、`application.throw_exception` イベントが通知されます。 +リクエスト処理のあいだに捕まえられない例外が投げられたときに `application.throw_exception` イベントが通知されます。 -このイベントをリスニングすることで、捕まらない例外が投げられたときに特別な対応を行うことができます (メールを送信する、もしくはエラーをロギングするなど)。イベントを処理することで、symfony のデフォルトの例外管理メカニズムをオーバーライドすることもできます。 +このイベントをリスニングしていれば、捕まえられない例外が投げられた場合に、メールを送信する、もしくはエラーログに記録するなどの措置を講じることができます。イベントを扱うことで、symfony におけるデフォルトの例外管理メカニズムをオーバーライドすることもできます。 `command` --------- @@ -181,7 +205,7 @@ | ------------ | ----------------------------------------------------------------------------------- | `priority` | 優先順位 (`sfLogger::EMERG`、`sfLogger::ALERT`、`sfLogger::CRIT`、`sfLogger::ERR`、 `sfLogger::WARNING`、`sfLogger::NOTICE`、`sfLogger::INFO` もしくは `sfLogger::DEBUG`) -`command.log` イベントは symfony CLI ユーティリティでロギングするために symfony によって利用されるメカニズムです (`logger` ファクトリを参照)。 +`command.log` イベントは symfony CLI ユーティリティによるロギングにも利用できます (`logger` ファクトリをご参照ください)。 ### ~`command.pre_command`~ @@ -210,11 +234,11 @@ *デフォルトの通知オブジェクト*: `sfTask` -| パラメータ | 説明 +| パラメータ | 説明 | ----------------- | ------------------------------- -| `command_manager` | `sfCommandManager` インスタンス +| `command_manager` | `sfCommandManager` のインスタンス -タスクオプションが CLI によってパースされる前に `command.filter_options` イベントが通知されます。このイベントはユーザーに渡すオプションをフィルタリングするために使うことができます。 +タスクオプションが CLI によってパースされる前に `command.filter_options` イベントが通知されます。このイベントはユーザーに渡すオプションにフィルタをかけます。 `configuration` --------------- @@ -230,7 +254,7 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfProjectConfiguration` クラスで定義されていなければ、`configuration.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfProjectConfiguration` クラスで定義されていなければ、`configuration.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 `component` ----------- @@ -241,12 +265,12 @@ *デフォルトの通知オブジェクト*: `sfComponent` -| パラメータ | 説明 +| パラメータ | 説明 | ------------ | ----------------------------------- | `method` | 呼び出されたが見つからないメソッド | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfComponent` クラスで定義されていないときに `component.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfComponent` クラスで定義されていなければ、`component.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 `context` --------- @@ -257,7 +281,20 @@ *デフォルトの通知オブジェクト*: `sfContext` -すべてのファクトリが初期化された直後から、リクエストがやって来るたびに、`sfContext` オブジェクトによって`context.load_factories` イベントが1回通知されます。すべてのコアクラスが初期化されるときに、このイベントが最初に通知されます。 +すべてのファクトリが初期化された直後から、リクエストが来るたびに、`sfContext` オブジェクトによって `context.load_factories` イベントが1回通知されます。すべてのコアクラスが初期化された際にこのイベントが最初に通知されます。 + +### `context.method_not_found` + +*通知メソッド*: `notifyUntil` + +*デフォルトの通知オブジェクト*: `sfContext` + +| パラメータ | 説明 +| ----------- | ----------------------------------- +| `method` | 呼び出されたが見つからないメソッド +| `arguments` | メソッドに渡される引数 + +`sfContext` クラスで定義されていないメソッドが呼び出された際に `context.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 `controller` ------------ @@ -273,7 +310,7 @@ | `module` | 実行されるモジュールの名前 | `action` | 実行されるアクションの名前 -アクションが実行される直前に `controller.change_action` が通知されます。 +アクションが実行される直前に `controller.change_action` イベントが通知されます。 ### ~`controller.method_not_found`~ @@ -286,7 +323,7 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfController` クラスで定義されていなければ、`controller.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfController` クラスで定義されていなければ、`controller.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 ### ~`controller.page_not_found`~ @@ -296,12 +333,119 @@ | パラメータ | 説明 | ------------ | ------------------------------------ -| `module` | 404エラーを生成するモジュールの名前 -| `action` | 404エラーを生成するアクションの名前 +| `module` | 404エラーが発生したモジュールの名前 +| `action` | 404エラーが発生したアクションの名前 + +リクエスト処理のあいだに404エラーが発生したときに `controller.page_not_found` イベントが通知されます。 + +このイベントをリスニングしていれば、404ページが表示されるときに、メールを送信する、エラー、イベントのログをとるなどの措置を講じることができます。 + +`debug` +------- + +### `debug.web.load_panels` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: `sfWebDebug` + +`sfWebDebug` インスタンスの `configure()` メソッドを呼び出した後に、`debug.web.load_panels` イベントが通知されます。このイベントをパネルの管理に使うことができます。 + +### `debug.web.view.filter_parameter_html` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: `sfWebDebugPanelView` + +| パラメータ | 説明 +| ----------- | ----------------------------- +| `parameter` | フィルタをかけるパラメータ + +`debug.web.view.filter_parameter_html` イベントは `sfWebDebugPanelView` パネルによってレンダリングされるそれぞれのパラメータにフィルタをかけます。 + +`doctrine` +---------- + +### `doctrine.configure` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: `sfDoctrinePluginConfiguration` + +Doctrine プラグインのコンフィギュレーションが変更された後で `doctrine.configure` イベントが通知されます。 + +### `doctrine.filter_model_builder_options` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: `sfDoctrinePluginConfiguration` + +`doctrine.filter_model_builder_options` イベントは Doctrine スキーマビルダーのオプションにフィルタをかけます。 + +### `doctrine.filter_cli_config` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: `sfDoctrinePluginConfiguration` + +`doctrine.filter_cli_config` イベントは Doctrine CLI のコンフィギュレーション配列にフィルタをかけます。 + +### `doctrine.configure_connection` + +*通知メソッド*: `notify` -リクエスト処理のあいだに404エラーが生成されたとき、`controller.page_not_found` が通知されます。 +*デフォルトの通知オブジェクト*: `Doctrine_Manager` (`sfDoctrineDatabase`) + +| パラメータ | 説明 +| ------------ | -------------------------------------- +| `connection` | `Doctrine_Connection` のインスタンス +| `database` | `sfDoctrineDatabase` のインスタンス + +Doctrine のデータベースオブジェクトがはじめて初期化されたときに `doctrine.configure_connection` イベントが通知されます。 + +### `doctrine.admin.delete_object` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: アドミンジェネレータのモジュールクラス + +| パラメータ | 説明 +| --------- | ------------------------------ +| `object` | 削除される Doctrine オブジェクト + +アドミンジェネレータモジュールのなかで Doctrine オブジェクトが削除されたときに `doctrine.admin.delete_object` イベントが通知されます。 + +### `doctrine.admin.save_object` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールのクラス + +| パラメータ | 説明 +| --------- | -------------------------------- +| `object` |保存される Doctrine オブジェクト -404ページが表示されるとき、メールを送信する、エラー、イベントをロギングするなど何か特別な対応を行うために、このイベントをリスニングできます。 +アドミンジェネレータモジュールのなかで Doctrine オブジェクトが保存されたときに `doctrine.admin.save_object` イベントが通知されます。 + +### `doctrine.admin.build_query` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールのクラス + +アドミンジェネレータモジュールのなかで Doctrine Query オブジェクトが生成されたときに `doctrine.admin.build_query` イベントが通知されます。 + +### `doctrine.admin.pre_execute` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールのクラス + +| パラメータ | 説明 +| ---------------- | ----------- +| `configuration` | アドミンジェネレータのコンフィギュレーションオブジェクト + +アドミンジェネレータモジュールの `preExecute()` メソッドが呼び出されたときに `doctrine.admin.pre_execute` イベントが通知されます。 `form` ------ @@ -312,7 +456,7 @@ *デフォルトの通知オブジェクト*: `sfFormSymfony` -`form.post_configure` イベントはフォームのコンフィギュレーションが変更されるときに通知されます。 +`form.post_configure` イベントはフォームのコンフィギュレーションが変更されたときに通知されます。 ### ~`form.filter_values`~ @@ -320,7 +464,7 @@ *デフォルトの通知オブジェクト*: `sfFormSymfony` -`form.filter_values` イベントは、バインドする直前の、マージされ、汚染されているパラメータとファイルの配列をフィルタリングします。 +`form.filter_values` イベントは、バインドされる直前の、マージされ、汚染されているパラメータとファイルの配列にフィルタをかけます。 ### ~`form.validation_error`~ @@ -345,7 +489,18 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfFormSymfony` クラスで定義されていなければ、`form.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfFormSymfony` クラスで定義されていなければ、`form.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 + +`mailer` +-------- + +### `mailer.configure` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: `sfMailer` + +メーラーのコンフィギュレーションが変更された後で `mailer.configure` イベントが通知されます。メーラーのインスタンスはイベントのサブジェクトです。 `plugin` -------- @@ -403,6 +558,83 @@ プラグインがアンインストールされた直後に `plugin.post_uninstall` イベントが通知されます。 +`propel` +-------- + +### `propel.configure` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: `sfPropelPluginConfiguration` + +Propel プラグインのコンフィギュレーションが変更された後で `propel.configure` イベントが通知されます。 + +### `propel.filter_phing_args` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: `sfPropelBaseTask` + +`propel.filter_phing_args` イベントは Propel CLI のコンフィギュレーション配列にフィルタをかけます。 + +### `propel.filter_connection_config` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: `sfPropelDatabase` + +| パラメータ | 説明 +| ------------ | ---------------------------------- +| `name` | コネクションの名前 +| `database` | `sfPropelDatabase` のインスタンス + +Propel +データベースが最初に初期化されたときに `propel.filter_connection_config` イベントが通知されます。 + +### `propel.admin.delete_object` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールのクラス + +| パラメータ | 説明 +| --------- | ----------- +| `object` | 削除される Propel オブジェクト + +Propel オブジェクトが削除されたときに `propel.admin.delete_object` イベントが通知されます。 + +### `propel.admin.save_object` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールのクラス + +| パラメータ | 説明 +| --------- | ------------------------------ +| `object` | 保存される Propel オブジェクト + +アドミンジェネレータモジュールのなかで Propel オブジェクトが保存されたときに `propel.admin.save_object` イベントが通知されます。 + +### `propel.admin.build_criteria` + +*通知メソッド*: `filter` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールのクラス + +アドミンジェネレータモジュールのなかで Propel の Criteria が生成されたときに `propel.admin.build_criteria` イベントが通知されます。 + +### `propel.admin.pre_execute` + +*通知メソッド*: `notify` + +*デフォルトの通知オブジェクト*: アドミンジェネレータモジュールクラス + +| パラメータ | 説明 +| ---------------- | --------------------------------------------------------- +| `configuration` | アドミンジェネレータのコンフィギュレーションオブジェクト + +アドミンジェネレータモジュールの `preExecute()` メソッドが呼び出されたときに `propel.admin.pre_execute` イベントが通知されます。 + `request` --------- @@ -416,7 +648,7 @@ | ------------ | ----------------- | `path_info` | リクエストのパス -リクエストパラメータが初期化されるときに `request.filter_parameters` イベントが通知されます。 +リクエストパラメータが初期化されたときに `request.filter_parameters` イベントが通知されます。 ### ~`request.method_not_found`~ @@ -429,7 +661,7 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfRequest` クラスで定義されていなければ、`request.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfRequest` クラスで定義されていなければ、`request.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 `response` ---------- @@ -445,7 +677,7 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfResponse` クラスで定義されていなければ、`response.method_not_found` イベントが通知されます。継承を使わなくても、このメソッドをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfResponse` クラスで定義されていなければ、`response.method_not_found` イベントが通知されます。このメソッドをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 ### ~`response.filter_content`~ @@ -453,7 +685,7 @@ *デフォルトの通知オブジェクト*: `sfResponse` -レスポンスが送信される前に `response.filter_content` イベントが通知されます。このイベントをリスニングすることで、送信される前のレスポンスの内容を操作できます。 +レスポンスが送信される前に `response.filter_content` イベントが通知されます。このイベントをリスニングしていれば、送信される前のレスポンスの内容に手を加えることができます。 `routing` --------- @@ -464,7 +696,7 @@ *デフォルトの通知オブジェクト*: `sfRouting` -ルーティングファクトリがルーティングコンフィギュレーションをロードするときに `routing.load_configuration` イベントが通知されます。 +ルーティングファクトリがルーティングコンフィギュレーションをロードしたときに `routing.load_configuration` イベントが通知されます。 `task` ------ @@ -481,7 +713,7 @@ | `type` | キャッシュの種類 (`all`、`config`、`i18n`、`routing`、`module`、そして `template`) | `env` | 環境 -キャッシュが `cache:clear` タスクによって一掃されるときに `task.cache.clear` イベントが通知されます。 +キャッシュが `cache:clear` タスクによって一掃されたときに `task.cache.clear` イベントが通知されます。 `template` ---------- @@ -492,7 +724,7 @@ *デフォルトの通知オブジェクト*: `sfViewParameterHolder` -ビューファイルがレンダリングされる前に `template.filter_parameters` イベントが通知されます。このイベントをリスニングすることで、テンプレートに渡される変数へのアクセスおよび操作ができます。 +ビューファイルがレンダリングされる前に `template.filter_parameters` イベントが通知されます。このイベントをリスニングしていれば、テンプレートに渡される変数にアクセスして、変数に収められている値を書き換えることができます。 `user` ------ @@ -507,7 +739,7 @@ | ----------- | ----------------- | `culture` | ユーザーカルチャ -リクエストのあいだにユーザーカルチャが変更されるときに `user.change_culture` イベントが通知されます。 +リクエストのあいだにユーザーカルチャが変更されたときに `user.change_culture` イベントが通知されます。 ### ~`user.method_not_found`~ @@ -520,7 +752,7 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfUser` クラスで定義されていなければ、`user.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfUser` クラスで定義されていなければ、`user.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 ### ~`user.change_authentication`~ @@ -545,11 +777,11 @@ | パラメータ | 説明 | ---------- | ------------------------------- -| `format` | リクエストされるフォーマット +| `format` | リクエストされたフォーマット | `response` | レスポンスオブジェクト | `request` | リクエストオブジェクト -リクエストにおいて `sf_format` パラメータセットが存在するときに `view.configure_format` イベントが通知されます。symfony が設定を変更するもしくはレイアウトの設定を解除するなどの単純な作業を行った後にこのイベントが通知されます。このイベントによってリクエストされるフォーマットに合わせてビューとレスポンスオブジェクトを変更することができます。 +リクエストにおいて `sf_format` パラメータセットが存在しているときに `view.configure_format` イベントが通知されます。symfony が設定を変更するもしくはレイアウトの設定を解除するなどの処理を施した後でこのイベントが通知されます。このイベントによってリクエストされたフォーマットに応じてビューとレスポンスオブジェクトを変更することができます。 ### ~`view.method_not_found`~ @@ -562,7 +794,7 @@ | `method` | 呼び出されたが見つからないメソッドの名前 | `arguments` | メソッドに渡される引数 -呼び出されたメソッドが `sfView` クラスで定義されていなければ、`view.method_not_found` イベントが通知されます。継承を使わなくても、このイベントをリスニングすることで、クラスにメソッドを追加できます。 +呼び出されたメソッドが `sfView` クラスで定義されていなければ、`view.method_not_found` イベントが通知されます。このイベントをリスニングしていれば、継承を使わなくても、クラスにメソッドを追加できます。 `view.cache` ------------ @@ -576,7 +808,7 @@ | パラメータ | 説明 | ---------- | ---------------------------------------------------------- | `response` | レスポンスオブジェクト -| `uri` | キャッシュ済みのコンテンツの URI +| `uri` | キャッシュずみのコンテンツの URI | `new` | コンテンツがキャッシュのなかで新しいものであるかどうか -`view.cache.filter_content` イベントはキャッシュからコンテンツが読み込まれるときに通知されます。 +`view.cache.filter_content` イベントはキャッシュからコンテンツが読み込まれるたびに通知されます。 diff --git a/reference/ja/16-Tasks.markdown b/reference/ja/16-Tasks.markdown index 90c0356..8e7de9d 100644 --- a/reference/ja/16-Tasks.markdown +++ b/reference/ja/16-Tasks.markdown @@ -1,31 +1,31 @@ タスク ====== -symfony フレームワークにはコマンドラインインターフェイス (CLI) ツールが搭載されています。組み込みタスクによってプロジェクト期間にさまざまな作業をこなすことができます。 +symfony フレームワークには CLI (コマンドラインインターフェイス) ツールが搭載されています。組み込みのタスクを利用することで、開発しているあいだのさまざまな作業が軽減されます。 -引数に何も渡さずに `symfony` コマンドを実行すると、利用可能なタスクの一覧が表示されます: +引数に何も渡さずに `symfony` コマンドを実行すると、利用可能なタスクの一覧が表示されます。 $ php symfony -`-V` オプションを渡せば、symfony のバージョンと CLI で使われる symfony ライブラリのパス情報が得られます: +`-V` オプションを渡すと、symfony のバージョンと CLI で使われる symfony ライブラリのパス情報が表示されます。 $ php symfony -V -CLI ツールはタスクの名前を第1引数にとります: +CLI ツールはタスクの名前を第1引数にとります。 $ php symfony list -タスクの名前は、コロン (`:`) で区切られる名前空間と名前で構成されます。名前空間はオプションです: +タスクの名前は、コロン (`:`) で区切られた名前空間と名前からなります。名前空間はオプションです。 $ php symfony cache:clear -引数とオプションはタスクの名前の後に渡します: +引数とオプションはタスクの名前の後に渡します。 $ php symfony cache:clear --type=template -CLI ツールは値の有無とオプションの長短バージョンの表記をそれぞれサポートします。 +CLI ツールは値の有無およびオプションの長短バージョンをそれぞれサポートしています。 -タスクにデバッグ情報を出力するよう指示する `-t` オプションはグローバルオプションです。 +`-t` オプションはグローバルオプションで、デバッグ情報の出力を意味します。
@@ -124,7 +124,7 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 ### ~`help`~ -`help` タスクはタスクのヘルプメッセージを表示する: +`help` タスクはタスクのヘルプメッセージを表示します。 $ php symfony help [--xml] [task_name] @@ -135,22 +135,22 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 | `task_name` | `help` | タスクの名前 -| オプション (ショートカット)| デフォルト |説明 -| ------------------------- | -------- | ------------------------- -| `--xml` | `-` | ヘルプメッセージを XML 形式で出力する +| オプション (ショートカット)| デフォルト |説明 +| ------------------------- | -------- | ----------------------------- +| `--xml` | `-` | ヘルプメッセージの出力形式が XML になります。 -`help` タスクは任意のタスクのヘルプメッセージを表示します: +`help` タスクは任意のタスクのヘルプメッセージを表示します。 ./symfony help test:all -`--xml` オプションをつければ、ヘルプメッセージを XML 形式で出力することもできます: +`--xml` オプションをつければ、ヘルプメッセージは XML 形式で出力されます。 ./symfony help test:all --xml ### ~`list`~ -`list` タスクはタスクの一覧を表示する: +`list` タスクは利用可能なタスクの一覧を表示します。 $ php symfony list [--xml] [namespace] @@ -161,20 +161,20 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 | `namespace` | `-` | 名前空間の名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ----------------------------- | ---------- | ------------------ -| `--xml` | `-` | ヘルプメッセージを XML 形式で出力する +| `--xml` | `-` | ヘルプメッセージの出力形式が XML になります -`list` タスクはすべてのタスクの一覧を表示します: +`list` タスクはすべてのタスクの一覧を表示します。 ./symfony list -特定の名前空間のタスクを表示することもできます: +特定の名前空間に属しているタスクの一覧を表示することもできます。 ./symfony list test -`--xml` オプションをつければ、情報を XML 形式で出力することもできます: +`--xml` オプションをつければ、出力形式は XML になります。 ./symfony list --xml @@ -183,7 +183,7 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 ### ~`app::routes`~ -`app::routes` タスクはアプリケーションにおける現在のルートを表示する: +`app::routes` タスクはアプリケーションにおける現在のルートを表示します。 $ php symfony app:routes application [name] @@ -197,7 +197,7 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 -`app:routes` はアプリケーションにおける現在のルートを表示します: +`app:routes` はアプリケーションにおける現在のルートを表示します。 ./symfony app:routes frontend @@ -206,44 +206,46 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 ### ~`cache::clear`~ -`cache::clear` タスクはキャッシュをクリアする: +`cache::clear` タスクはキャッシュをクリアします。 - $ php symfony cache:clear [--app[="..."]] [--env[="..."]] [--type[="..."]] + $ php symfony cache:clear [--app[="..."]] [--env[="..."]] [--type[="..."]] *エイリアス*: `cc` -| オプション (ショートカット) | デフォルト| 説明 +| オプション (ショートカット) | デフォルト| 説明 | ---------------------------- | ---------- | ---------------------- | `--app` | `-` | アプリケーションの名前 | `--env` | `-` | 環境 | `--type` | `all` | 種類 -`cache:clear` タスクは symfony のキャッシュをクリアします。 +`cache:clear` タスクはアプリケーションのキャッシュをクリアします。 デフォルトでは、このタスクはすべての利用可能な種類、すべてのアプリケーションとすべての環境のキャッシュを削除します。 -種類、アプリケーションもしくは環境で制限できます: +クリアするキャッシュは種類、アプリケーションもしくは環境で選別することができます。 -たとえば、`frontend` アプリケーションのキャッシュをクリアするには: +たとえば `frontend` アプリケーションのキャッシュをクリアするには、`--app` オプションを指定します。 ./symfony cache:clear --app=frontend -`frontend` アプリケーションにおける `prod` 環境のキャッシュをクリアするには: +`frontend` アプリケーションにおける `prod` 環境のキャッシュをクリアするには、`--env` オプションも指定します。 ./symfony cache:clear --app=frontend --env=prod -すべての `prod` 環境のキャッシュをクリアするには: +`prod` 環境においてすべてのキャッシュをクリアするには、`--env` オプションだけを指定します。 ./symfony cache:clear --env=prod -`prod` 環境の `config` キャッシュをクリアするには: +`prod` 環境の `config` キャッシュをクリアするには、`--type` オプションを指定します。 ./symfony cache:clear --type=config --env=prod -`--type` オプション組み込まれている引数は次のとおりです: `config`、`i18n`、`routing`、`module` と `template` +`--type` オプションに組み込まれている引数は次のとおりです。 + +`config`、`i18n`、`routing`、`module` と `template` `configure` @@ -251,43 +253,43 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 ### ~`configure::author`~ -`configure::author` タスクはプロジェクトにおけるコードの著者を設定する: +`configure::author` タスクはプロジェクトにおけるコードの著者の名前を設定します。 $ php symfony configure:author author | 引数 | デフォルト| 説明 -| -------- | ---------- | ---------------------------------- -| `author` | `-` | プロジェクトにおけるコードの著者 +| -------- | ---------- | -------------------------------------- +| `author` | `-` | プロジェクトにおけるコードの著者の名前 -`configure:author` タスクはプロジェクトにおけるコードの著者を設定します: +`configure:author` タスクはプロジェクトにおけるコードの著者の名前を設定します。 ./symfony configure:author "Fabien Potencier " -それぞれの生成ファイルのなかで PHPDoc ヘッダーをあらかじめ用意しておくために、ジェネレータは著者の名前を使います。 +ジェネレータはそれぞれの生成ファイルのなかで PHPDoc ヘッダーを用意する際に著者の名前を使います。 -値は `config/properties.ini` に保存されます。 +著者の名前は `config/properties.ini` ファイルに保存されます。 ### ~`configure::database`~ -`configure::database` タスクはデータベースの DSN を設定する: +`configure::database` タスクはデータベースの DSN を設定します。 $ php symfony configure:database [--env[="..."]] [--name[="..."]] [--class[="..."]] [--app[="..."]] dsn [username] [password] -| 引数 | デフォルト | 説明 +| 引数 | デフォルト| 説明 | ---------- | --------- | --------------------------- | `dsn` | `-` | データベースの DSN | `username` | `root` | データベースユーザーの名前 | `password` | `-` | データベースのパスワード -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | -------------------- | ------------------------ | `--env` | `all` | 環境 | `--name` | `doctrine` | コネクションの名前 @@ -295,68 +297,68 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 | `--app` | `-` | アプリケーションの名前 -`configure:database` タスクはプロジェクトにおけるデータベースの DSN を設定します: +`configure:database` タスクはプロジェクトにおけるデータベースの DSN を設定します。 ./symfony configure:database mysql:host=localhost;dbname=example root mYsEcret -デフォルトでは、このタスクはすべての環境のコンフィギュレーションを変更します。特定の環境に合わせて DSN を変更したいのであれば、`env` オプションをつけます: +デフォルトでは、このタスクはすべての環境のコンフィギュレーションを変更します。環境ごとに DSN を変更したいのであれば、`--env` オプションを指定します。 ./symfony configure:database --env=dev mysql:host=localhost;dbname=example_dev root mYsEcret -特定のアプリケーションのコンフィギュレーションを変更するには、`app` オプションをつけます: +特定のアプリケーションのコンフィギュレーションを変更するには、`--app` オプションを指定します。 ./symfony configure:database --app=frontend mysql:host=localhost;dbname=example root mYsEcret -データベースコネクションの名前とクラスの名前を指定することもできます: +データベースコネクションの名前とクラスの名前も指定できます。 ./symfony configure:database --name=main --class=ProjectDatabase mysql:host=localhost;dbname=example root mYsEcret >**WARNING** -> `Propel` データベースを使う場合、`app` オプションをつけずに `all` 環境を設定すれば、`propel.ini` ファイルも更新されます。 +> `Propel` を使う場合、`--app` オプションを指定せずに `--all` 環境のコンフィギュレーションを変更すれば、`propel.ini` ファイルも更新されます。 `doctrine` ---------- ### ~`doctrine::build`~ -`doctrine::build` タスクはスキーマに対応するコードを生成する: +`doctrine::build` タスクはスキーマに対応したコードを生成します。 - $ php symfony doctrine:build [--application[="..."]] [--env="..."] [--no-confirmation] [--all] [--all-classes] [--model] [--forms] [--filters] [--sql] [--db] [--and-migrate] [--and-load[="..."]] [--and-append[="..."]] + $ php symfony doctrine:build [--application[="..."]] [--env="..."] [--no-confirmation] [--all] [--all-classes] [--model] [--forms] [--filters] [--sql] [--db] [--and-migrate] [--and-load[="..."]] [--and-append[="..."]] -| オプション (ショートカット) | デフォルト | 説明 -| -------------------------- | --------- | --------------------------------------------------------- +| オプション (ショートカット) | デフォルト | 説明 +| --------------------------- | ---------- | --------------------------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev`| 環境 | `--no-confirmation` | `-` | データベースの削除を強制するか -| `--all` | `-` | すべてをビルドしてデータベースをリセットする -| `--all-classes` | `-` | すべてのクラスをビルドする -| `--model` | `-` | モデルクラスをビルドする -| `--forms` | `-` | フォームクラスをビルドする -| `--filters` | `-` | フィルタクラスをビルドする -| `--sql` | `-` | SQL をビルドする -| `--db` | `-` | SQL を削除、作成もしくは挿入する、もしくはデータベースをマイグレートする -| `--and-migrate` | `-` | データベースをマイグレートする -| `--and-load` | `-` | フィクスチャデータをロードする (複数の値が可能) -| `--and-append` | `-` | フィクスチャデータを追加する (複数の値が可能) +| `--all` | `-` | すべてをビルドしてデータベースをリセットします +| `--all-classes` | `-` | すべてのクラスをビルドします +| `--model` | `-` | モデルクラスをビルドします +| `--forms` | `-` | フォームクラスをビルドします +| `--filters` | `-` | フィルタクラスをビルドします +| `--sql` | `-` | SQL をビルドします +| `--db` | `-` | SQL を削除、作成もしくは挿入する、もしくはデータベースをマイグレートします +| `--and-migrate` | `-` | データベースをマイグレートします +| `--and-load` | `-` | フィクスチャデータをロードします (複数の値が可能です) +| `--and-append` | `-` | フィクスチャデータを追加します (複数の値が可能です) -`doctrine:build` タスクはスキーマに対応するコードを生成します: +`doctrine:build` タスクはスキーマに対応したコードを生成します。 ./symfony doctrine:build -ビルドしたいものを指定しなければなりません。たとえば、モデルとフォームクラスをビルドしたいのであれば、`--model` と `--forms` オプションをつけます: +ビルドしたいものを指定しなければなりません。たとえば、モデルとフォームクラスをビルドしたいのであれば、`--model` と `--forms` オプションをつけます。 ./symfony doctrine:build --model --forms -すべてのクラスと SQL を生成してデータベースを再構築したいのであれば、ショートカットの `--all` オプションをつけます: +すべてのクラスと SQL を生成してデータベースを再構築したいのであれば、ショートカットの `--all` オプションをつけます。 ./symfony doctrine:build --all -上記の例は次のタスクの組み合わせと同じです: +上記の例は次のタスクの組み合わせと同じです。 ./symfony doctrine:drop-db ./symfony doctrine:build-db @@ -366,64 +368,64 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 ./symfony doctrine:build-sql ./symfony doctrine:insert-sql -ショートカットの `--all-classes` オプションをつければ、クラスファイルだけを生成することもできます。このオプションが単独でつけられるとき、データベースは修正されません。 +ショートカットの `--all-classes` オプションをつけると、クラスファイルだけが生成されます。このオプションを単独でつけると、データベースは修正されません。 ./symfony doctrine:build --all-classes -`--and-migrate` オプションをつければ、ビルドが完了したときにマイグレーションの追加が実行されます: +`--and-migrate` オプションをつければ、ビルドが完了したときに保留中のマイグレーションが実行されます。 ./symfony doctrine:build --db --and-migrate -`--and-load` オプションをつければ、プロジェクトとプラグインの `data/fixtures/` ディレクトリからデータがロードされます: +`--and-load` オプションをつければ、プロジェクトとプラグインの `data/fixtures/` ディレクトリからデータがロードされます。 ./symfony doctrine:build --db --and-migrate --and-load -ロードするフィクスチャを指定するには、`--and-load` オプションにパラメータを加えます: +指定したフィクスチャをロードの対象に加えるには、フィクスチャのパスを `--and-load` オプションに加えます。 ./symfony doctrine:build --all --and-load="data/fixtures/dev/" -データベースのレコードを削除せずにフィクスチャを追加するには、`--and-append` オプションをつけます: +データベースのレコードを削除せずにフィクスチャを追加するには、`--and-append` オプションをつけます。 ./symfony doctrine:build --all --and-append ### ~`doctrine::build-db`~ -`doctrine::build-db` タスクは現在のモデルに対応するデータベースを作る: +`doctrine::build-db` タスクは現在のモデルに対応したデータベースを作ります。 $ php symfony doctrine:build-db [--application[="..."]] [--env="..."] [database1] ... [databaseN] *エイリアス*: `doctrine:create-db` -| 引数 | デフォルト | 説明 -| ---------- | --------- | ----------- +| 引数 | デフォルト | 説明 +| ---------- | --------- | ------------------- | `database` | `-` | 特定のデータベース -| オプション (ショートカット)| デフォルト | 説明 +| オプション (ショートカット)| デフォルト | 説明 | --------------------------- | ----------- | ----------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:build-db` タスクは `config/databases.yml` のコンフィギュレーションをもとに1つもしくは複数のデータベースを作ります: +`doctrine:build-db` タスクは `config/` ディレクトリにある `databases.yml` ファイルのコンフィギュレーションをもとに1つもしくは複数のデータベースを作ります。 ./symfony doctrine:build-db -作るデータベースの名前を指定することもできます: +作るデータベースの名前を指定することもできます。 ./symfony doctrine:build-db slave1 slave2 ### ~`doctrine::build-filters`~ -`doctrine::build-filters` タスクは現在のモデルに対応するフィルタフォームクラスを作る: +`doctrine::build-filters` タスクは現在のモデルに対応したフィルタフォームクラスを作ります。 - $ php symfony doctrine:build-filters [--application[="..."]] [--env="..."] [--model-dir-name="..."] [--filter-dir-name="..."] [--generator-class="..."] + $ php symfony doctrine:build-filters [--application[="..."]] [--env="..."] [--model-dir-name="..."] [--filter-dir-name="..."] [--generator-class="..."] -| オプション
(ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ------------------- | -------- | ------------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 @@ -432,25 +434,25 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 | `--generator-class` | `sfDoctrineFormFilterGenerator` | ジェネレータクラス -`doctrine:build-filters` タスクはスキーマに対応するフォームフィルタクラスを作ります: +`doctrine:build-filters` タスクはスキーマに対応したフォームフィルタクラスを作ります。 ./symfony doctrine:build-filters -モデルに対応するフォームフィルタクラスが `lib/doctrine/filter` に作られます。 +モデルに対応したフォームフィルタクラスは `lib/doctrine/filter/` ディレクトリに作られます。 -このタスクが `lib/doctrine/filter` のカスタムクラスを上書きすることはけっしてありません。このタスクは `lib/doctrine/filter/base` に生成される基底クラスを置き換えるだけです。 +このタスクが `lib/doctrine/filter/` ディレクトリにあるカスタムクラスを上書きすることはけっしてありません。このタスクは `lib/doctrine/filter/base/` ディレクトリに生成された基底クラスを置き換えるだけです。 ### ~`doctrine::build-forms`~ -`doctrine::build-forms` タスクは現在のモデルに対応するフォームクラスを作る: +`doctrine::build-forms` タスクは現在のモデルに対応したフォームクラスを作ります。 - $ php symfony doctrine:build-forms [--application[="..."]] [--env="..."] [--model-dir-name="..."] [--form-dir-name="..."] [--generator-class="..."] + $ php symfony doctrine:build-forms [--application[="..."]] [--env="..."] [--model-dir-name="..."] [--form-dir-name="..."] [--generator-class="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ------------------- | -------- | ------------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 @@ -459,108 +461,108 @@ CLI ツールは値の有無とオプションの長短バージョンの表記 | `--generator-class` | `sfDoctrineFormFilterGenerator` | ジェネレータクラス -`doctrine:build-forms` タスクはスキーマに対応するフォームクラスを作ります: +`doctrine:build-forms` タスクはスキーマに対応したフォームクラスを作ります。 ./symfony doctrine:build-forms -このタスク実行では、モデルに対応するフォームクラスが `lib/doctrine/form` に作られます。 +上記の例では、モデルに対応したフォームクラスが `lib/doctrine/form/` ディレクトリに作られます。 -このタスクは `lib/doctrine/form` のカスタムクラスを上書きすることはけっしてありません。このタスクは `lib/doctrine/form/base` に生成された基底クラスだけを置き換えるだけです。 +このタスクは `lib/doctrine/form/` ディレクトリにあるカスタムクラスを上書きすることはけっしてありません。このタスクは `lib/doctrine/form/base/` ディレクトリに生成された基底クラスだけを置き換えるだけです。 ### ~`doctrine::build-model`~ -`doctrine::build-model` タスクは現在のモデルに対応するクラスを作る: +`doctrine::build-model` タスクは現在のモデルに対応したクラスを作ります。 - $ php symfony doctrine:build-model [--application[="..."]] [--env="..."] + $ php symfony doctrine:build-model [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | -------- | ------------------------ | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:build-model` タスクはスキーマに対応するモデルクラスを作ります: +`doctrine:build-model` タスクはスキーマに対応したモデルクラスを作ります。 ./symfony doctrine:build-model -このタスクはプロジェクトと有効なすべてのプラグインから `config/doctrine/*.yml` のスキーマ情報を読み込みます。 +このタスクはプロジェクトと有効なプラグインの `config/doctrine/` ディレクトリに配置されているすべての YAML スキーマファイルの情報を読み込みます。 -モデルクラスファイルは `lib/model/doctrine` に作られます。 +モデルクラスファイルは `lib/model/doctrine/` ディレクトリに作られます。 -このタスクは `lib/model/doctrine` のなかのカスタムタスクを上書きすることはけっしてありません。このタスクは `lib/model/doctrine/base` のファイルだけを置き換えます。 +このタスクは `lib/model/doctrine/` ディレクトリのなかのカスタムタスクを上書きすることはけっしてありません。このタスクは `lib/model/doctrine/base/` ディレクトリのファイルだけを置き換えます。 ### ~`doctrine::build-schema`~ -`doctrine::build-schema` タスクは既存のデータベースに対応するスキーマを作る: +`doctrine::build-schema` タスクは既存のデータベースに対応したスキーマを作ります。 - $ php symfony doctrine:build-schema [--application[="..."]] [--env="..."] + $ php symfony doctrine:build-schema [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ----------- | ----------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:build-schema` タスクはスキーマの基準になるデータベースをイントロスペクトします: +`doctrine:build-schema` タスクはスキーマのもとになるデータベースをイントロスペクトします。 ./symfony doctrine:build-schema -YAML ファイルが `config/doctrine` に作ります。 +YAML ファイルが `config/doctrine` ディレクトリに作られます。 ### ~`doctrine::build-sql`~ -`doctrine::build-sql` タスクは現在のモデルに対応する SQL を生成する: +`doctrine::build-sql` タスクは現在のモデルに対応した SQL 文を生成します。 - $ php symfony doctrine:build-sql [--application[="..."]] [--env="..."] + $ php symfony doctrine:build-sql [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ------- | ---------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:build-sql` タスクはテーブル作成の SQL 文を生成します: +`doctrine:build-sql` タスクはテーブル作成の SQL 文を生成します。 ./symfony doctrine:build-sql -生成される SQL は `config/databases.yml` で設定されているデータベースに合わせて最適化されます: +生成される SQL 文は `config/` ディレクトリにある `databases.yml` ファイルで指定されているデータベースに合わせて最適化されます。 doctrine.database = mysql ### ~`doctrine::clean-model-files`~ -`doctrine::clean-model-files` タスクは YAML スキーマにもはや存在しないモデルに対応して生成されたすべてのモデルクラスを削除する: +`doctrine::clean-model-files` タスクは YAML スキーマにもはや存在しないモデルに合わせて生成されたモデルクラスをすべて削除します。 - $ php symfony doctrine:clean-model-files [--no-confirmation] + $ php symfony doctrine:clean-model-files [--no-confirmation] *エイリアス*: `doctrine:clean` -| オプション (ショートカット) | デフォルト | 説明 -| ---------------------------- | ------- | ------------------------- -| `--no-confirmation` | `-` | 確認メッセージを省略する +| オプション (ショートカット) | デフォルト | 説明 +| ---------------------------- | ------- | --------------------------- +| `--no-confirmation` | `-` | 確認メッセージを省略します -`doctrine:clean-model-files` タスクはプロジェクトもしくはプラグインの `schema.yml` ファイルに存在しないモデルクラスを削除します: +`doctrine:clean-model-files` タスクはプロジェクトもしくはプラグインの `schema.yml` ファイルに存在しないモデルクラスを削除します。 ./symfony doctrine:clean-model-files ### ~`doctrine::create-model-tables`~ -`doctrine::create-model-tables` タスクは指定されるモデルのテーブルを削除した後で再作成する: +`doctrine::create-model-tables` タスクは指定されたモデルのテーブルを削除した後で再作成します。 $ php symfony doctrine:create-model-tables [--application[="..."]] [--env="..."] [models1] ... [modelsN] @@ -571,19 +573,19 @@ YAML ファイルが `config/doctrine` に作ります。 | `models` | `-` | モデルのリスト -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ---------- | ---------------------- | `--application` | `frontend` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:create-model-tables` は指定されるモデルのテーブルを削除した後で再作成します: +`doctrine:create-model-tables` タスクは指定されたモデルのテーブルを削除した後で再作成します。 ./symfony doctrine:create-model-tables User ### ~`doctrine::data-dump`~ -`doctrine::data-dump` タスクはデータをフィクスチャディレクトリに吐き出す: +`doctrine::data-dump` タスクはデータベースのデータをフィクスチャディレクトリに吐き出します。 $ php symfony doctrine:data-dump [--application[="..."]] [--env="..."] [target] @@ -594,80 +596,80 @@ YAML ファイルが `config/doctrine` に作ります。 | `target` | `-` | ターゲットのファイル名 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | ---------- | ---------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:data-dump` タスクはデータベースデータを吐き出します: +`doctrine:data-dump` タスクはデータベースのデータを吐き出します。 ./symfony doctrine:data-dump -データベースのデータは `data/fixtures/%target%` に吐き出されます。 +データベースのデータは `data/fixtures/%target%/` ディレクトリに吐き出されます。 -`doctrine:data-load` タスクを使うことで、吐き出された YAML フォーマットのファイルを再インポートできます。 +吐き出された YAML ファイルを再インポートするには `doctrine:data-load` タスクを使います。 ./symfony doctrine:data-load ### ~`doctrine::data-load`~ -`doctrine::data-load` タスクは YAML フィクスチャデータをロードする: +`doctrine::data-load` タスクは YAML フィクスチャのデータをロードします。 $ php symfony doctrine:data-load [--application[="..."]] [--env="..."] [--append] [dir_or_file1] ... [dir_or_fileN] | 引数 | デフォルト | 説明 -| ------------- | ------- | -------------------------------------- -| `dir_or_file` | `-` | ロードするディレクトリもしくはファイル +| ------------- | ---------- | ----------------------------------------------- +| `dir_or_file` | `-` | ロードの対象となるディレクトリもしくはファイル -| オプション(ショートカット)| デフォルト | 説明 +| オプション (ショートカット)| デフォルト | 説明 | ---------------------- | ----------- | ---------------------- | `--application`| `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -| `--append` | `-` | データベースの現在の値を削除しない +| `--append` | `-` | データベースの現在のデータは削除しません -`doctrine:data-load` タスクはデータベースにデータフィクスチャをロードさせます: +`doctrine:data-load` タスクはデータベースにフィクスチャのデータをロードさせます。 ./symfony doctrine:data-load -`data/fixtures/` で見つかるすべてのファイルからデータがロードされます。 +`data/fixtures/` ディレクトリで見つかるすべてのファイルからデータがロードされます。 -特定のファイルもしくはディレクトリからデータをロードさせたければ、引数にこれらを渡します: +特定のファイルもしくはディレクトリからデータをロードしたいのであれば、引数にこれらのパスを渡します。 ./symfony doctrine:data-load data/fixtures/dev data/fixtures/users.yml -データベースにおける既存のデータを削除したくなければ、`--append` オプションをつけます: +データベースにおける既存のデータを削除したくなければ、`--append` オプションをつけます。 ./symfony doctrine:data-load --append ### ~`doctrine::delete-model-files`~ -`doctrine::delete-model-files` タスクは任意のモデル名に関連する自動生成ファイルをすべて削除する: +`doctrine::delete-model-files` タスクは任意のモデルに関連した自動生成ファイルをすべて削除します。 $ php symfony doctrine:delete-model-files [--no-confirmation] name1 ... [nameN] | 引数 | デフォルト | 説明 -| ------ | ------ | --------------------------------------------------- -| `name` | `-` | 削除したいすべてのファイルに関連するモデルの名前 +| ------ | ------ | ------------------------------------------------ +| `name` | `-` | 削除したいすべてのファイルに関連したモデルの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ------------------- | ---- | -------------------------- -| `--no-confirmation` | `-` | 確認メッセージを省略する +| `--no-confirmation` | `-` | 確認メッセージを省略します -`doctrine:delete-model-files` タスクは特定のモデルに関連するすべてのファイルを削除します: +`doctrine:delete-model-files` タスクは特定のモデルに関連したすべてのファイルを削除します。 ./symfony doctrine:delete-model-files Article Author ### ~`doctrine::dql`~ -`doctrine::dql` タスクは DQL クエリを実行して結果を表示する: +`doctrine::dql` タスクは DQL クエリを実行して結果を表示します。 $ php symfony doctrine:dql [--application[="..."]] [--env="..."] [--show-sql] [--table] dql_query [parameter1] ... [parameterN] @@ -679,29 +681,29 @@ YAML ファイルが `config/doctrine` に作ります。 | `parameter` | `-` | クエリパラメータ -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ------------------------ | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -| `--show-sql` | `-` | 実行される SQL を表示する -| `--table` | `-` | 結果を表形式で返す +| `--show-sql` | `-` | 実行される SQL 文を表示します +| `--table` | `-` | 結果を表形式で返します -`doctrine:dql` タスクは DQL クエリを実行して整えられた結果を表示します: +`doctrine:dql` タスクは DQL クエリを実行して結果を整えて表示します。 ./symfony doctrine:dql "FROM User" -`--show-sql` オプションをつければ、実行される SQL を表示できます: +`--show-sql` オプションをつけると、実行される SQL 文が表示されます。 ./symfony doctrine:dql --show-sql "FROM User" -追加の引数にクエリパラメータを渡すことができます: +追加のクエリパラメータを引数に渡すことができます。 ./symfony doctrine:dql "FROM User WHERE email LIKE ?" "%symfony-project.com" ### ~`doctrine::drop-db`~ -`doctrine::drop-db` タスクは現在のモデルに対応するデータベースを削除する: +`doctrine::drop-db` タスクは現在のモデルに対応したデータベースを削除します。 $ php symfony doctrine:drop-db [--application[="..."]] [--env="..."] [--no-confirmation] [database1] ... [databaseN] @@ -712,28 +714,28 @@ YAML ファイルが `config/doctrine` に作ります。 | `database` | `-` | 特定のデータベース -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 | `--no-confirmation` | `-` | データベースの削除を強制するか -`doctrine:drop-db` タスクは `config/databases.yml` のコンフィギュレーションをもとに1つもしくは複数のデータベースを削除します: +`config/` ディレクトリに配置されている `databases.yml` ファイルのコンフィギュレーションをもとに `doctrine:drop-db` タスクは1つもしくは複数のデータベースを削除します。 ./symfony doctrine:drop-db -`--no-confirmation` オプションをつけないかぎり、このタスクはデータベースを削除してよいのか確認を求めてきます: +`--no-confirmation` オプションをつけないかぎり、タスクからデータベースを削除してよいのかたずねられます。 ./symfony doctrine:drop-db --no-confirmation -削除したいデータベースの名前を指定できます: +削除したいデータベースの名前を指定できます。 ./symfony doctrine:drop-db slave1 slave2 ### ~`doctrine::generate-admin`~ -`doctrine::generate-admin` タスクは Doctrine アドミンモジュールを生成する: +`doctrine::generate-admin` タスクは Doctrine に対応したアドミンモジュールを生成します。 $ php symfony doctrine:generate-admin [--module="..."] [--theme="..."] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route_or_model @@ -745,7 +747,7 @@ YAML ファイルが `config/doctrine` に作ります。 | `route_or_model` | `-` | ルートの名前もしくはモデルクラス -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | ---------- | ----------------- | `--module` | `-` | モジュールの名前 | `--theme` | `admin` | テーマの名前 @@ -755,31 +757,31 @@ YAML ファイルが `config/doctrine` に作ります。 | `--actions-base-class` | `sfActions`| アクションの基底クラス -`doctrine:generate-admin` タスクは Doctrine アドミンモジュールを生成します: +`doctrine:generate-admin` タスクは Doctrine に対応したアドミンモジュールを生成します。 ./symfony doctrine:generate-admin frontend Article -上記の例では、`%frontend%` アプリケーションのなかで `%Article%` モデルに対応するモジュールが生成されます。 +上記の例では、`%Article%` モデルに対応したモジュールが `%frontend%` アプリケーションに生成されます。 -このタスクはアプリケーションの `routing.yml` のなかでルートを作ります。 +ルートはアプリケーションの `routing.yml` ファイルに用意されます。 -ルートの名前を渡すことで Doctrine アドミンモジュールを生成することもできます: +ルートの名前を引数に渡すことで、Doctrine アドミンモジュールを生成することもできます。 ./symfony doctrine:generate-admin frontend article -上記の例では、`%frontend%` アプリケーションのなかで `routing.yml` で見つかる `%article%` ルートに対応するモジュールが生成されます。 +上記の例では、`routing.yml` ファイルで定義されている `%article%` ルートに対応したモジュールが `%frontend%` アプリケーションに生成されます。 -フィルタとバッチアクションを適切に動かすには、ルートのコンフィギュレーションで `wildcard` オプションを指定する必要があります: +フィルタとバッチアクションがきちんと動くようにするには、ルートのコンフィギュレーションのなかで `wildcard` オプションに `true` をセットする必要があります。 article: - class: sfDoctrineRouteCollection - options: - model: Article - with_wildcard_routes: true + class: sfDoctrineRouteCollection + options: + model: Article + with_wildcard_routes: true ### ~`doctrine::generate-migration`~ -`doctrine::generate-migration` タスクはマイグレーションクラスを生成する: +`doctrine::generate-migration` タスクはマイグレーションクラスを生成します。 $ php symfony doctrine:generate-migration [--application[="..."]] [--env="..."] [--editor-cmd="..."] name @@ -790,32 +792,32 @@ YAML ファイルが `config/doctrine` に作ります。 | `name` | `-` | マイグレーションの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ----------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -| `--editor-cmd` | `-` | このコマンドでスクリプトを開く +| `--editor-cmd` | `-` | このコマンドでスクリプトを開きます `doctrine:generate-migration` タスクはマイグレーションテンプレートを生成します。 ./symfony doctrine:generate-migration AddUserEmailColumn -新しいマイグレーションクラスをエディタの作成メニューで開くには、`--editor-cmd` オプションをつけます: +新しいマイグレーションクラスをエディタの作成メニューで開くには、`--editor-cmd` オプションを指定します。 ./symfony doctrine:generate-migration AddUserEmailColumn --editor-cmd=mate ### ~`doctrine::generate-migrations-db`~ -`doctrine::generate-migrations-db` タスクは既存のデータベースコネクションからマイグレーションクラスを生成する: +`doctrine::generate-migrations-db` タスクは既存のデータベースコネクションからマイグレーションクラスを生成します。 - $ php symfony doctrine:generate-migrations-db [--application[="..."]] [--env="..."] + $ php symfony doctrine:generate-migrations-db [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ------------------------ | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 @@ -827,35 +829,35 @@ YAML ファイルが `config/doctrine` に作ります。 ### ~`doctrine::generate-migrations-diff`~ -`doctrine::generate-migrations-diff` タスクは新旧のスキーマの差分を作り出すことでマイグレーションクラスを生成する: +`doctrine::generate-migrations-diff` タスクは新旧のスキーマの差分からマイグレーションクラスを生成します。 - $ php symfony doctrine:generate-migrations-diff [--application[="..."]] [--env="..."] + $ php symfony doctrine:generate-migrations-diff [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ------- | ----------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:generate-migrations-diff` タスクは、新旧のスキーマの差分を作り出すことでマイグレーションクラスを生成します。 +`doctrine:generate-migrations-diff` タスクは新旧のスキーマの差分からマイグレーションクラスを生成します。 ./symfony doctrine:generate-migrations-diff ### ~`doctrine::generate-migrations-models`~ -`doctrine::generate-migrations-models` タスクは既存のモデルセットからマイグレーションクラスを生成する: +`doctrine::generate-migrations-models` タスクは既存のモデルセットからマイグレーションクラスを生成します。 - $ php symfony doctrine:generate-migrations-models [--application[="..."]] [--env="..."] + $ php symfony doctrine:generate-migrations-models [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ---------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 @@ -867,7 +869,7 @@ YAML ファイルが `config/doctrine` に作ります。 ### ~`doctrine::generate-module`~ -`doctrine::generate-module` タスクは Doctrine モジュールを生成する: +`doctrine::generate-module` タスクは Doctrine に対応したモジュールを生成します。 $ php symfony doctrine:generate-module [--theme="..."] [--generate-in-cache] [--non-verbose-templates] [--with-show] [--singular="..."] [--plural="..."] [--route-prefix="..."] [--with-doctrine-route] [--env="..."] [--actions-base-class="..."] application module model @@ -880,12 +882,12 @@ YAML ファイルが `config/doctrine` に作ります。 | `model` | `-` | モデルクラスの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ---------------------------------- | `--theme` | `default` | テーマの名前 -| `--generate-in-cache` | `-` | キャッシュでモジュールを生成する -| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成する -| `--with-show` | `-` | show メソッドを生成する +| `--generate-in-cache` | `-` | キャッシュでモジュールを生成します +| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成します +| `--with-show` | `-` | show メソッドを生成します | `--singular` | `-` | 単数形の名前 | `--plural` | `-` | 複数形の名前 | `--route-prefix` | `-` | ルートのプレフィックス @@ -894,29 +896,29 @@ YAML ファイルが `config/doctrine` に作ります。 | `--actions-base-class` | `sfActions` | アクションの基底クラス -`doctrine:generate-module` タスクは Doctrine のモジュールを生成します: +`doctrine:generate-module` タスクは Doctrine に対応したモジュールを生成します。 ./symfony doctrine:generate-module frontend article Article -上記の例では、`%application%` アプリケーションのなかで `%model%` モデルクラスに対応する `%module%` モジュールが生成されます。 +上記の例では、`%model%` モデルクラスに対応した `%module%` モジュールが `%application%` アプリケーションに生成されます。 -`--generate-in-cache` オプションをつければ、`%sf_app_cache_dir%/modules/auto%module%` のなかで実行時に生成されるモジュールからアクションとテンプレートを継承する空のモジュールを作ることもできます: +`--generate-in-cache` オプションをつけると、実行時に生成されるモジュールからアクションとテンプレートを継承する空のモジュールが `%sf_app_cache_dir%/modules/auto%module%/` ディレクトリに作られます。 ./symfony doctrine:generate-module --generate-in-cache frontend article Article -`--theme` オプションをつければ、ジェネレータはカスタマイズ済みのテーマを使います: +`--theme` オプションを指定すれば、カスタマイズずみのテーマが使われます。 ./symfony doctrine:generate-module --theme="custom" frontend article Article -この方法では、独自仕様に合わせてモジュールジェネレータを作ることができます。 +この方法では、自分のスタイルに合わせてモジュールジェネレータを作ることができます。 -生成モジュールに使われるアクションの基底クラス (デフォルトは `sfActions`) を変更することもできます: +生成モジュールに使われるアクションの基底クラスに変更することもできます (デフォルトは `sfActions`)。 ./symfony doctrine:generate-module --actions-base-class="ProjectActions" frontend article Article ### ~`doctrine::generate-module-for-route`~ -`doctrine::generate-module-for-route` タスクはルート定義に対応する Doctrine モジュールを生成する: +`doctrine::generate-module-for-route` タスクは Doctrine のルート定義に対応したモジュールを生成します。 $ php symfony doctrine:generate-module-for-route [--theme="..."] [--non-verbose-templates] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route @@ -928,47 +930,47 @@ YAML ファイルが `config/doctrine` に作ります。 | `route` | `-` | ルートの名前 -| オプション (ショートカット) | デフォルト | 説明 -| ----------------------------- | ---------- | --------------------------------- +| オプション (ショートカット) | デフォルト | 説明 +| ----------------------------- | ---------- | -------------------------------------- | `--theme` | `default` | テーマの名前 -| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成する +| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成します | `--singular` | `-` | 単数形の名前 | `--plural` | `-` | 複数形の名前 | `--env` | `dev` | 環境 | `--actions-base-class` | `sfActions`| アクションの基底クラス -`doctrine:generate-module-for-route` タスクはルート定義に対応する Doctrine モジュールを生成します: +`doctrine:generate-module-for-route` タスクはルート定義に対応した Doctrine モジュールを生成します。 ./symfony doctrine:generate-module-for-route frontend article -上記の例では、`%frontend%` アプリケーションのなかで `routing.yml` の `%article%` ルート定義に対応するモジュールが生成されます。 +上記の例では、`routing.yml` ファイルの `%article%` ルート定義に対応したモジュールが `%frontend%` アプリケーションに生成されます。 ### ~`doctrine::insert-sql`~ -`doctrine::insert-sql` タスクは現在のモデルに対応するテーブルを作る: +`doctrine::insert-sql` タスクは現在のモデルに対応したテーブルを作ります。 - $ php symfony doctrine:insert-sql [--application[="..."]] [--env="..."] + $ php symfony doctrine:insert-sql [--application[="..."]] [--env="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ------- | ---------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -`doctrine:insert-sql` タスクはデータベースのテーブルを作ります: +`doctrine:insert-sql` タスクはデータベースのテーブルを作ります。 ./symfony doctrine:insert-sql -このタスクはデータベースコネクションを確立し、すべての `lib/model/doctrine/*.class.php` ファイルに対応するテーブルを作ります。 +このタスクはデータベースに接続し、`lib/model/doctrine/` ディレクトリにある `*.class.php` ファイルに対応したテーブルを作ります。 ### ~`doctrine::migrate`~ -`doctrine::migrate` タスクはデータベースを現在の/指定バージョンにマイグレートする: +`doctrine::migrate` タスクはデータベースを現在の/指定されたバージョンにマイグレートします。 $ php symfony doctrine:migrate [--application[="..."]] [--env="..."] [--up] [--down] [--dry-run] [version] @@ -979,28 +981,28 @@ YAML ファイルが `config/doctrine` に作ります。 | `version` | `-` | マイグレートするバージョン -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | --------------- |---- | -------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 -| `--up` | `-` | あるバージョンにマイグレートアップする -| `--down` | `-` | あるバージョンにマイグレートダウンする -| `--dry-run` | `-` | マイグレーションを続けない +| `--up` | `-` | あるバージョンにマイグレートアップします +| `--down` | `-` | あるバージョンにマイグレートダウンします +| `--dry-run` | `-` | マイグレーションをつづけません -`doctrine:migrate` タスクはデータベースをマイグレートします: +`doctrine:migrate` タスクはデータベースをマイグレートします。 ./symfony doctrine:migrate -特定のバージョンにマイグレートするには、引数にバージョンを渡します: +特定のバージョンにマイグレートするには、引数にバージョン番号を渡します。 ./symfony doctrine:migrate 10 -あるバージョンにマイグレートアップもしくはマイグレートダウンするには、`--up` もしくは `--down` オプションをつけます: +あるバージョンにマイグレートアップもしくはマイグレートダウンするには、`--up` もしくは `--down` オプションをつけます。 ./symfony doctrine:migrate --down -データベースが DDL 文のロールバックをサポートするのであれば、`--dry-run` オプションをつけると、マイグレーションをドライモードで実行できます: +データベースが DDL 文のロールバックをサポートしている場合、`--dry-run` オプションをつければ、マイグレーションはドライモードで実行されます。 ./symfony doctrine:migrate --dry-run @@ -1009,7 +1011,7 @@ YAML ファイルが `config/doctrine` に作ります。 ### ~`generate::app`~ -`generate::app` タスクは新しいアプリケーションを生成する: +`generate::app` タスクは新しいアプリケーションを生成します。 $ php symfony generate:app [--escaping-strategy="..."] [--csrf-secret="..."] app @@ -1020,40 +1022,40 @@ YAML ファイルが `config/doctrine` に作ります。 | `app` | `-` | アプリケーションの名前 -| オプション (ショートカット) | デフォルト | 説明 -| ---------------------------- | ------- | ---------------------------- -| `--escaping-strategy` | `1` | エスケーピング戦略を出力する -| `--csrf-secret` | `1` | CSRF 防止に使う秘密の文字列 +| オプション (ショートカット) | デフォルト | 説明 +| ---------------------------- | ------- | ------------------------------------ +| `--escaping-strategy` | `1` | エスケーピングストラテジを出力します +| `--csrf-secret` | `1` | CSRF 対策に使う秘密の文字列 -`generate:app` タスクは、現在のプロジェクトにおいて新しいアプリケーションの基本ディレクトリ構造を作ります: +`generate:app` タスクは現在のプロジェクトにおいて新しいアプリケーションの基本ディレクトリ構造を作ります。 ./symfony generate:app frontend -2つのフロントコントローラも `web/` ディレクトリに作られます: +2つのフロントコントローラも `web/` ディレクトリに作られます。 web/%application%.php 運用環境 web/%application%_dev.php 開発環境 最初のアプリケーションに関して、運用環境のスクリプトの名前は `index.php` です。 -すでに同じ名前のアプリケーションが存在する場合、`sfCommandException` が投げられます。 +同じ名前のアプリケーションがすでに存在している場合、`sfCommandException` のインスタンスが投げられます。 デフォルトでは、XSS を防ぐために出力エスケーピングが有効で、CSRF も防ぐためにランダムな秘密の文字列が生成されます。 -`escaping-strategy` オプションをつければ、出力エスケーピングを無効にできます: +`--escaping-strategy` オプションを指定すれば、出力エスケーピングを無効にできます。 ./symfony generate:app frontend --escaping-strategy=false -(CSRF を防ぐために) `csrf-secret` オプションで秘密の文字列を指定すれば、フォームのセッショントークンを有効にできます: +(CSRF を防ぐために) 秘密の文字列を `--csrf-secret` オプションで指定すれば、フォームのセッショントークンを有効にできます。 ./symfony generate:app frontend --csrf-secret=UniqueSecret -`%sf_data_dir%/skeleton/app` ディレクトリを作れば、タスクが使うデフォルトのスケルトンをカスタマイズできます。 +`%sf_data_dir%/skeleton/app/` ディレクトリを用意すれば、タスクが使うデフォルトのスケルトンをカスタマイズできます。 ### ~`generate::module`~ -`generate::module` タスクは新しいモジュールを生成する: +`generate::module` タスクは新しいモジュールを生成します。 $ php symfony generate:module application module @@ -1067,104 +1069,104 @@ YAML ファイルが `config/doctrine` に作ります。 -`generate:module` タスクは、既存のアプリケーションにおいて新しいモジュールの基本ディレクトリ構造を作ります: +`generate:module` タスクは既存のアプリケーションにおいて新しいモジュールの基本ディレクトリ構造を作ります。 ./symfony generate:module frontend article -著者の名前が `config/properties.ini` で指定されている場合、タスクは `actions.class.php` でも名前を変更することができます: +`config/` ディレクトリに配置されている `properties.ini` ファイルのなかで著者が指定されている場合、タスクは `actions.class.php` ファイルのなかの名前も変更することができます。 [symfony] - name=blog - author=Fabien Potencier + name=blog + author=Fabien Potencier -`%sf_data_dir%/skeleton/module` ディレクトリを作ることで、タスクが使うデフォルトのスケルトンをカスタマイズできます。 +`%sf_data_dir%/skeleton/module/` ディレクトリを用意すれば、タスクが使うデフォルトのスケルトンをカスタマイズできます。 -`%sf_test_dir%/functional/%application%/%module%ActionsTest.class.php` という名前の機能テストのスタブも作られます。デフォルトでは、このテストのスタブは通りません。 +`ActionsTest.class.php` という名前の機能テストのスタブも `%sf_test_dir%/functional/%application%/%module/` ディレクトリに作られます。デフォルトでは、このテストのスタブは通りません。 -すでにアプリケーションのなかに同じ名前のモジュールがある場合、`sfCommandException` が投げられます。 +すでにアプリケーションのなかに同じ名前のモジュールが存在している場合、`sfCommandException` のインスタンスが投げられます。 ### ~`generate::project`~ -`generate::project` タスクは新しいプロジェクトを生成する: +`generate::project` タスクは新しいプロジェクトを生成します。 $ php symfony generate:project [--orm="..."] [--installer="..."] name [author] -| 引数 | デフォルト | 説明 +| 引数 | デフォルト | 説明 | -------- | ---------------- | ------------------ | `name` | `-` | プロジェクトの名前 | `author` | `Your name here` | プロジェクトの著者 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ------------- | ------------- | --------------------------------- -| `--orm` | `Doctrine` | デフォルトで使う ORM +| `--orm` | `Doctrine` | デフォルトで使われる ORM | `--installer` | `-` | 実行するインストーラスクリプト -`generate:project` タスクは、現在のディレクトリにおいて新しいプロジェクトの基本ディレクトリ構造を作ります: +`generate:project` タスクは現在のディレクトリにおいて新しいプロジェクトの基本ディレクトリ構造を作ります。 ./symfony generate:project blog -すでに現在のディレクトリが symfony のプロジェクトに収められている場合、`sfCommandException` が投げられます。 +すでに同じ名前のプロジェクトが存在している場合、`sfCommandException` のインスタンスが投げられます。 -デフォルトでは、タスクは Doctrine を ORM に設定します。Propel を使いたければ、`--orm` オプションで指定します: +タスクが使うデフォルトの ORM は Doctrine です。Propel を使いたければ、`--orm` オプションで指定します。 ./symfony generate:project blog --orm=Propel -ORM を使いたくなければ、`--orm` オプションに `none` を渡します: +ORM を使いたくなければ、`--orm` オプションに `none` を渡します。 ./symfony generate:project blog --orm=none -プロジェクトを細かくカスタマイズするために `--installer` オプションを指定することもできます: +`--installer` オプションを指定してプロジェクトを細かくカスタマイズすることもできます。 ./symfony generate:project blog --installer=./installer.php -symfony が新しいクラスを生成する際に、オプションとして著者を指名するには、第2引数に `author` を渡します: +オプションとして、新しいクラスの著者の名前を第2引数に渡して指名することができます。 ./symfony generate:project blog "Jack Doe" ### ~`generate::task`~ -`generate::task` タスクは新しいタスクのスケルトンクラスを作る: +`generate::task` タスクは新しいタスクのスケルトンクラスを作ります。 $ php symfony generate:task [--dir="..."] [--use-database="..."] [--brief-description="..."] task_name | 引数 | デフォルト | 説明 -| ----------- | ------- | ---------------------------------------------- -| `task_name` | `-` | タスクの名前 (名前空間がつく) +| ----------- | ------- | ---------------------------------- +| `task_name` | `-` | タスクの名前 (名前空間がつきます) -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------- | ---------- | ------------------------------------------------------------ -| `--dir` | `lib/task` | タスクを作るディレクトリ +| `--dir` | `lib/task` | タスクが配置されるディレクトリ | `--use-database` | `doctrine` | タスクがデータベースにアクセスするモデルの初期化を必要とするか -| `--brief-description`| `-` | 短いタスクの説明 (タスクのリストに表示される) +| `--brief-description`| `-` | タスクの短い説明 (タスクのリストに表示されます) -`generate:task` は、引数に渡される名前をもとに `sfBaseTask` クラスを継承する新しいクラスを作ります: +`generate:task` タスクは引数に渡された名前をもとに `sfBaseTask` 基底クラスを継承する新しいクラスを作ります。 ./symfony generate:task namespace:name -`namespaceNameTask.class.php` スケルトンタスクは `lib/task/` ディレクトリに作られます。名前空間はオプションであることにご注意ください。 +`namespaceNameTask.class.php` タスクのスケルトンは `lib/task/` ディレクトリに作られます。名前空間がオプションであることにご注意ください。 -別のディレクトリ (プロジェクトのルートフォルダに相対的な位置) でファイルを作りたければ、`--dir` オプションで指定します。指定したディレクトリがまだ存在していなければ作られます。 +タスクファイルが作られるディレクトリを変更したいのであれば、`--dir` オプションで指定します (プロジェクトのルートフォルダに対して相対的な位置)。指定したディレクトリがまだ存在していなければ作られます。 ./symfony generate:task namespace:name --dir=plugins/myPlugin/lib/task -デフォルトの `doctrine` 以外のコネクションを利用したければ、`--use-database` オプションにコネクションの名前を指定します: +デフォルトの `doctrine` 以外のコネクションを利用したいのであれば、`--use-database` オプションにコネクションの名前を指定します。 ./symfony generate:task namespace:name --use-database=main -`--use-database` オプションは、生成タスクでデータベースの初期化を無効化するためにも使うことができます: +`--use-database` オプションはデータベースの初期化を無効にする場合にも使うことができます。 ./symfony generate:task namespace:name --use-database=false -タスクの説明を指定することもできます: +タスクの説明を指定することもできます。 ./symfony generate:task namespace:name --brief-description="Does interesting things" @@ -1173,7 +1175,7 @@ symfony が新しいクラスを生成する際に、オプションとして著 ### ~`i18n::extract`~ -`i18n::extract` タスクは PHP ファイルから国際化対応の文字列を抽出する: +`i18n::extract` タスクは PHP ファイルから国際対応した文字列を抽出します。 $ php symfony i18n:extract [--display-new] [--display-old] [--auto-save] [--auto-delete] application culture @@ -1185,39 +1187,39 @@ symfony が新しいクラスを生成する際に、オプションとして著 | `culture` | `-` | ターゲットのカルチャ -| オプション (ショートカット) | デフォルト | 説明 -| -------------------------- | --------- | ------------------------- -| `--display-new` | `-` | 新しく見つかるすべての文字列を出力する -| `--display-old` | `-` | すべての古い文字列を出力する -| `--auto-save` | `-` | 新しい文字列を保存する -| `--auto-delete` | `-` | 古い文字列を削除する +| オプション (ショートカット) | デフォルト | 説明 +| -------------------------- | ----------- | ------------------------------ +| `--display-new` | `-` | 新たに見つかるすべての文字列を出力します +| `--display-old` | `-` | すべての古い文字列を出力します +| `--auto-save` | `-` | 新しい文字列を保存します +| `--auto-delete` | `-` | 古い文字列を削除します -`i18n:extract` タスクはアプリケーションとターゲットのカルチャのプロジェクトファイルから国際化対応の文字列を抽出します: +`i18n:extract` タスクはアプリケーションとターゲットのカルチャのプロジェクトファイルから国際対応した文字列を抽出します。 ./symfony i18n:extract frontend fr デフォルトでは、このタスクは現在のプロジェクトで見つかる新旧の文字列の数だけを表示します。 -新しい文字列を表示したければ、`--display-new` オプションをつけます: +新しい文字列を表示したいのであれば、`--display-new` オプションをつけます。 ./symfony i18n:extract --display-new frontend fr -これらの文字列を国際化対応メッセージカタログに保存するには、`--auto-save` オプションをつけます: +これらの文字列を国際対応したメッセージのカタログに保存するには、`--auto-save` オプションをつけます。 ./symfony i18n:extract --auto-save frontend fr -国際化対応メッセージカタログで見つかるが、アプリケーションで見つからない文字列を表示したければ、`--display-old` オプションをつけます: +国際対応したメッセージのカタログで見つかるが、アプリケーションで見つからない文字列を表示したければ、`--display-old` オプションをつけます。 ./symfony i18n:extract --display-old frontend fr -古い文字列を自動的に削除するには `--auto-delete` をつけますが、特にプラグインの翻訳がある場合、表示されるのは、現在の文字列ではなく古い文字列であることにご注意ください: +古い文字列を自動的に削除するには `--auto-delete` オプションをつけますが、特にプラグインの翻訳がある場合、表示されるのは、現在の文字列ではなく古い文字列であることにご注意ください。 ./symfony i18n:extract --auto-delete frontend fr ### ~`i18n::find`~ -`i18n::find` タスクはアプリケーションにおける「国際化未対応の」文字列を見つける: +`i18n::find` タスクはアプリケーションのなかの「国際対応していない」文字列を見つける。 $ php symfony i18n:find [--env="..."] application @@ -1228,30 +1230,30 @@ symfony が新しいクラスを生成する際に、オプションとして著 | `application` | `-` | アプリケーションの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | ---------- | ----------- | `--env` | `dev` | 環境 -`i18n:find` タスクはテンプレートに埋め込まれている国際化未対応の文字列を見つけます: +`i18n:find` タスクはテンプレートに埋め込まれた国際対応していない文字列を見つけます。 ./symfony i18n:find frontend -このタスクは純粋な HTML と PHP コードのなかで国際化未対応の文字列を見つけることができます: +このタスクは純粋な HTML と PHP コードのなかで国際対応していない文字列を見つけることができます。

Non i18n text

-このタスクは PHP コードに埋め込まれているすべての文字列を返しますが、誤検出する可能性があります (特に文字列構文をヘルパーの引数に使う場合)。 +このタスクは PHP コードに埋め込まれたすべての文字列を返しますが、誤検出する可能性があります (特に文字列構文をヘルパーの引数に使う場合)。 `log` ----- ### ~`log::clear`~ -`log::clear` タスクはログファイルをクリアする: +`log::clear` タスクはログファイルをクリアします。 - $ php symfony log:clear + $ php symfony log:clear @@ -1259,13 +1261,13 @@ symfony が新しいクラスを生成する際に、オプションとして著 -`log:clear` タスクはすべての symfony ログをクリアします: +`log:clear` タスクはすべてのログをクリアします。 ./symfony log:clear ### ~`log::rotate`~ -`log::rotate` タスクはアプリケーションにおけるログファイルのローテーションを行う: +`log::rotate` タスクはアプリケーションにおいてログファイルのローテーションを実行します。 $ php symfony log:rotate [--history="..."] [--period="..."] application env @@ -1277,17 +1279,17 @@ symfony が新しいクラスを生成する際に、オプションとして著 | `env` | `-` | 環境の名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | -------------- | ---------------------- | `--history` | `10` | 保存する古いログファイルの最大個数 | `--period` | `7` | 日にち単位の保存期間 -`log:rotate` タスクは任意の環境のアプリケーションにおいてログファイルのローテーションを行います: +`log:rotate` タスクは任意の環境のアプリケーションにおいてログファイルのローテーションを実行します。 ./symfony log:rotate frontend dev -`period` もしくは `history` オプションを指定できます: +`--period` もしくは `--history` オプションを指定できます。 ./symfony log:rotate frontend dev --history=10 --period=7 @@ -1296,7 +1298,7 @@ symfony が新しいクラスを生成する際に、オプションとして著 ### ~`plugin::add-channel`~ -`plugin::add-channel` タスクは新しい PEAR チャンネルを追加する: +`plugin::add-channel` タスクは新しい PEAR チャンネルを追加します。 $ php symfony plugin:add-channel name @@ -1309,13 +1311,13 @@ symfony が新しいクラスを生成する際に、オプションとして著 -`plugin:add-channel` タスクは新しい PEAR チャンネルを追加します: +`plugin:add-channel` タスクは新しい PEAR チャンネルを追加します。 ./symfony plugin:add-channel symfony.plugins.pear.example.com ### ~`plugin::install`~ -`plugin::install` タスクはプラグインをインストールする: +`plugin::install` タスクはプラグインをインストールします。 $ php symfony plugin:install [-s|--stability="..."] [-r|--release="..."] [-c|--channel="..."] [-d|--install_deps] [--force-license] name @@ -1326,7 +1328,7 @@ symfony が新しいクラスを生成する際に、オプションとして著 | `name` | `-` | プラグインの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ------- | ------------------------------------ | `--stability`
`(-s)` | `-` | 安定性 (stable、beta、alpha) | `--release`
`(-r)` | `-` | 優先バージョン @@ -1335,49 +1337,49 @@ symfony が新しいクラスを生成する際に、オプションとして著 | `--force-license` | `-` | MIT のようなライセンスではない場合にインストールを強制するか -`plugin:install` タスクはプラグインをインストールします: +`plugin:install` タスクはプラグインをインストールします。 ./symfony plugin:install sfGuardPlugin デフォルトでは、最新の `stable` リリースがインストールされます。 -まだ安定版ではないプラグインをインストールしたければ、`stability` オプションを指定します: +まだ安定版ではないプラグインをインストールしたければ、`--stability` オプションを指定します。 ./symfony plugin:install --stability=beta sfGuardPlugin ./symfony plugin:install -s beta sfGuardPlugin -特定のバージョンのインストールを強制することもできます: +特定のバージョンのインストールを強制することもできます。 ./symfony plugin:install --release=1.0.0 sfGuardPlugin ./symfony plugin:install -r 1.0.0 sfGuardPlugin -依存の必須パッケージをすべて強制的にインストールするには、`install_deps` フラグを指定します: +依存の必須パッケージをすべて強制的にインストールするには、`--install_deps` オプションを指定します。 ./symfony plugin:install --install-deps sfGuardPlugin ./symfony plugin:install -d sfGuardPlugin デフォルトで使われる PEAR チャンネルは `symfony-plugins` (plugins.symfony-project.org) です。 -`channel` オプションで別のチャンネルを指定できます: +別のチャンネルを `--channel` オプションで指定できます。 ./symfony plugin:install --channel=mypearchannel sfGuardPlugin ./symfony plugin:install -c mypearchannel sfGuardPlugin -Web サイトでホストされている PEAR パッケージをインストールすることもできます: +PEAR パッケージがホストされている Web サイトの URL を直接指定してインストールすることもできます。 ./symfony plugin:install http://somewhere.example.com/sfGuardPlugin-1.0.0.tgz -もしくはローカルな PEAR パッケージをインストールすることができます: +もしくはローカルな PEAR パッケージをインストールすることができます。 ./symfony plugin:install /home/fabien/plugins/sfGuardPlugin-1.0.0.tgz -プラグインにサイトのコンテンツ (画像、スタイルシートもしくは JavaScript) が収められている場合、このタスクはこれらのアセットのために `web/` の下で `%name%` シンボリックリンクを作ります。Windows では、このタスクはこれらすべてのファイルを `web/%name%` ディレクトリにコピーします。 +プラグインにサイトのコンテンツ (画像、スタイルシートもしくは JavaScript) が収められている場合、このタスクはこれらのアセットのために `web/` ディレクトリの下で `%name%` シンボリックリンクを作ります。Windows では、このタスクはこれらすべてのファイルを `web/%name%/` ディレクトリにコピーします。 ### ~`plugin::list`~ -`plugin::list` タスクはインストール済みのプラグインの一覧を表示する: +`plugin::list` タスクはインストールずみのプラグインの一覧を表示します。 - $ php symfony plugin:list + $ php symfony plugin:list @@ -1385,7 +1387,7 @@ Web サイトでホストされている PEAR パッケージをインストー -`plugin:list` タスクはインストール済みのプラグインの一覧を表示します: +`plugin:list` タスクはインストールずみのプラグインの一覧を表示します。 ./symfony plugin:list @@ -1393,7 +1395,7 @@ Web サイトでホストされている PEAR パッケージをインストー ### ~`plugin::publish-assets`~ -`plugin::publish-assets` タスクはすべてのプラグインからサイトのアセットを公開する: +`plugin::publish-assets` タスクはすべてのプラグインからサイトのアセットを公開します。 $ php symfony plugin:publish-assets [--core-only] [plugins1] ... [pluginsN] @@ -1401,12 +1403,12 @@ Web サイトでホストされている PEAR パッケージをインストー | 引数 | デフォルト | 説明 | --------- | ------ | ------------------------------- -| `plugins` | `-` | プラグインのアセットを公開する +| `plugins` | `-` | プラグインのアセットを公開します -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ------------------------------------------------------------- -| `--core-only` | `-` | セットされていれば、コアプラグインのみがアセットを公開する +| `--core-only` | `-` | セットされていれば、コアプラグインのみがアセットを公開します `plugin:publish-assets` タスクはすべてのプラグインからサイトのアセットを公開します。 @@ -1415,13 +1417,13 @@ Web サイトでホストされている PEAR パッケージをインストー 実際、このタスクは `plugin.post_install` イベントをそれぞれのプラグインに送信します。 -引数にこれらのプラグインの名前を渡すことで、1つもしくは複数のプラグインにアセットをインストールするかどうかを指示できます: +1つもしくは複数のプラグインにアセットをインストールするには、これらのプラグインの名前を引数に渡します。 ./symfony plugin:publish-assets sfDoctrinePlugin ### ~`plugin::uninstall`~ -`plugin::uninstall` タスクはプラグインをアンインストールする: +`plugin::uninstall` タスクはプラグインをアンインストールします。 $ php symfony plugin:uninstall [-c|--channel="..."] [-d|--install_deps] name @@ -1432,25 +1434,25 @@ Web サイトでホストされている PEAR パッケージをインストー | `name` | `-` | プラグインの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ------- | --------------------------------------- | `--channel`
`(-c)` | `-` | PEAR チャンネル名 | `--install_deps`
`(-d)` | `-` | 依存パッケージのインストールを強制するか -`plugin:uninstall` タスクはプラグインをアンインストールします: +`plugin:uninstall` タスクはプラグインをアンインストールします。 ./symfony plugin:uninstall sfGuardPlugin デフォルトのチャンネルは `symfony` です。 -異なるチャンネルにあるプラグインをアンインストールすることもできます: +異なるチャンネルで配布されているプラグインをアンインストールすることもできます。 ./symfony plugin:uninstall --channel=mypearchannel sfGuardPlugin ./symfony plugin:uninstall -c mypearchannel sfGuardPlugin -もしくは `channel/package` の表記を使うことができます: +もしくは `channel/package` の表記を選ぶことができます。 ./symfony plugin:uninstall mypearchannel/sfGuardPlugin @@ -1460,7 +1462,7 @@ Web サイトでホストされている PEAR パッケージをインストー ### ~`plugin::upgrade`~ -`plugin::upgrade` タスクはプラグインをアップグレードする: +`plugin::upgrade` タスクはプラグインをアップグレードします。 $ php symfony plugin:upgrade [-s|--stability="..."] [-r|--release="..."] [-c|--channel="..."] name @@ -1471,31 +1473,31 @@ Web サイトでホストされている PEAR パッケージをインストー | `name` | `-` | プラグイン名 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ----------------- | ------- | ------------------ | `--stability`
`(-s)` | `-` | 優先される安定性 (stable、beta、alpha) | `--release`
`(-r)` | `-` | 優先されるバージョン | `--channel`
`(-c)` | `-` | PEAR チャンネル名 -`plugin:upgrade` タスクはプラグインをアップグレードしようとします: +`plugin:upgrade` タスクはプラグインをアップグレードしようとします。 ./symfony plugin:upgrade sfGuardPlugin デフォルトのチャンネルは `symfony` です。 -サイトのコンテンツ (画像、スタイルシートもしくは JavaScript) がプラグインに収められている場合、Windows において、このタスクは `web/%name%` ディレクトリの内容を更新します。 +サイトのコンテンツ (画像、スタイルシートもしくは JavaScript) がプラグインに収められている場合、Windows において、このタスクは `web/%name%/` ディレクトリの内容を更新します。 -プラグインの名前とオプションのフォーマットの詳しい情報は `plugin:install` を参照してください。 +プラグインの名前とオプションのフォーマットのくわしい説明は `plugin:install` タスクをご参照ください。 `project` --------- ### ~`project::clear-controllers`~ -`project::clear-controllers` タスクは運用環境以外のすべての環境のコントローラをクリアする: +`project::clear-controllers` タスクは運用環境以外のすべての環境のコントローラをクリアします。 - $ php symfony project:clear-controllers + $ php symfony project:clear-controllers @@ -1503,29 +1505,29 @@ Web サイトでホストされている PEAR パッケージをインストー -`project:clear-controllers` タスクは運用環境以外のすべての環境のコントローラをクリアします: +`project:clear-controllers` タスクは運用環境以外のすべての環境のコントローラをクリアします。 ./symfony project:clear-controllers -運用サーバーにおいて、運用コントローラスクリプト以外のすべてのフロントコントローラを削除するために、このタスクを使うことができます。 +運用サーバーにおいて、運用環境以外のすべてのフロントコントローラのスクリプトを削除したい場合に、このタスクを使うことができます。 -`frontend` と `backend` という名前の2つのアプリケーションがある場合、4つのデフォルトコントローラが `web/` に用意されています: +`frontend` と `backend` という名前の2つのアプリケーションがある場合、4つのデフォルトコントローラが `web/` ディレクトリに配置されます。 index.php frontend_dev.php backend.php backend_dev.php -`project:clear-controllers` タスクを実行した後で、2つのコントローラスクリプトが　`web/` に残されます: +`project:clear-controllers` タスクを実行すると、2つのコントローラスクリプトが　`web/` ディレクトリに残されます。 index.php backend.php -これらの2つのコントローラはデバッグモードとデバッグツールバーが無効なので安全です。 +これらの2つのコントローラではデバッグモードとデバッグツールバーが無効なので安全です。 ### ~`project::deploy`~ -`project::deploy` タスクはプロジェクトを別のサーバーにデプロイする: +`project::deploy` タスクはプロジェクトを別のサーバーにデプロイします。 $ php symfony project:deploy [--go] [--rsync-dir="..."] [--rsync-options[="..."]] server @@ -1537,52 +1539,52 @@ Web サイトでホストされている PEAR パッケージをインストー -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ------- | ----------- -| `--go` | `-` | デプロイを実行する +| `--go` | `-` | デプロイを実行します | `--rsync-dir` | `config` | `rsync*.txt` ファイルを探すディレクトリ | `--rsync-options` | `-azC --force --delete --progress` | rsync の実行ファイルに渡すオプションの値 -`project:deploy` タスクはプロジェクトをサーバーにデプロイします: +`project:deploy` タスクはプロジェクトをサーバーにデプロイします。 ./symfony project:deploy production -このタスクのコンフィギュレーションは `config/properties.ini` のなかで変更します: +このタスクのコンフィギュレーションは `config/` ディレクトリに配置されている `properties.ini` ファイルのなかで変更します。 [production] - host=www.example.com - port=22 - user=fabien - dir=/var/www/sfblog/ - type=rsync + host=www.example.com + port=22 + user=fabien + dir=/var/www/sfblog/ + type=rsync -このタスクは、デプロイを自動化するために SSH を通して rsync を使います。SSH アクセスをキーで設定するもしくは パスワードを `config/properties.ini` のなかで指定しなければなりません。 +このタスクはデプロイを自動化するために SSH を通じて rsync を使います。SSH アクセスをキーで設定するもしくはパスワードを `config/` ディレクトリに配置されている `properties.ini` ファイルのなかで指定しなければなりません。 -デフォルトでは、タスクはドライモードです。本当にデプロイを実行するには、`--go` オプションを指定しなければなりません: +デフォルトでは、このタスクはドライモードです。本当にデプロイを実行するには、`--go` オプションを指定しなければなりません。 ./symfony project:deploy --go production -`config/rsync_exclude.txt` で指定されているファイルとディレクトリはデプロイされません: +`config/rsync_exclude.txt` ファイルで指定されているファイルとディレクトリはデプロイされません。 .svn /web/uploads/* /cache/* /log/* -`rsync.txt` と `rsync_include.txt` ファイルを作ることもできます。 +自前の `rsync.txt` と `rsync_include.txt` ファイルを用意することもできます。 -サーバーに合わせて `rsync*.txt` ファイルをカスタマイズする必要がある場合、`rsync-dir` オプションを指定します: +サーバーに合わせて `rsync*.txt` ファイルをカスタマイズする必要がある場合、`--rsync-dir` オプションを指定します。 ./symfony project:deploy --go --rsync-dir=config/production production -最後に、`rsync-options` オプションを指定すれば、rsync の実行ファイルのオプションを指定できます (デフォルトは `-azC --force --delete --progress`): +最後に、rsync コマンドのオプションはタスクの `--rsync-options` オプションを通じて指定できます (デフォルトは `-azC --force --delete --progress`)。 ./symfony project:deploy --go --rsync-options=-avz ### ~`project::disable`~ -`project::disable` タスクは任意の環境のアプリケーションを無効にする: +`project::disable` タスクは任意の環境のアプリケーションを無効にします。 $ php symfony project:disable env [app1] ... [appN] @@ -1596,17 +1598,17 @@ Web サイトでホストされている PEAR パッケージをインストー -`project:disable` タスクは環境を無効にします: +`project:disable` タスクは環境を無効にします。 ./symfony project:disable prod -特定の環境で無効にするアプリケーションを個別に指定することもできます: +特定の環境で無効にするアプリケーションを個別に指定することもできます。 ./symfony project:disable prod frontend backend ### ~`project::enable`~ -`project::enable` タスクは任意の環境のアプリケーションを有効にする: +`project::enable` タスクは任意の環境のアプリケーションを有効にします。 $ php symfony project:enable env [app1] ... [appN] @@ -1620,17 +1622,17 @@ Web サイトでホストされている PEAR パッケージをインストー -`project:enable` タスクは特定の環境を有効にします: +`project:enable` タスクは特定の環境を有効にします。 ./symfony project:enable frontend prod -特定の環境で有効にするアプリケーションを個別に指定することもできます: +特定の環境で有効にするアプリケーションを個別に指定することもできます。 ./symfony project:enable prod frontend backend ### ~`project::optimize`~ -`project::optimize` タスクはパフォーマンス改善のためにプロジェクトを最適化する: +`project::optimize` タスクはパフォーマンス改善のためにプロジェクトを最適化します。 $ php symfony project:optimize application [env] @@ -1644,17 +1646,17 @@ Web サイトでホストされている PEAR パッケージをインストー -`project:optimize` はパフォーマンス改善のためにプロジェクトを最適化します: +`project:optimize` はパフォーマンス改善のためにプロジェクトを最適化します。 ./symfony project:optimize frontend prod -このタスクを使う場所は運用サーバーに限定すべきです。プロジェクトのコードを修正するたびにタスクを再実行することをお忘れなく。 +このタスクを実行する場所は運用サーバーに限定すべきです。プロジェクトのコードを修正するたびにタスクを再実行することをお忘れなく。 ### ~`project::permissions`~ -`project::permissions` タスクは symfony のディレクトリのパーミッションを修正する: +`project::permissions` タスクは symfony のディレクトリのパーミッションを修正します。 - $ php symfony project:permissions + $ php symfony project:permissions @@ -1662,21 +1664,21 @@ Web サイトでホストされている PEAR パッケージをインストー -`project:permissions` タスクはディレクトリのパーミッションを修正します: +`project:permissions` タスクはディレクトリのパーミッションを修正します。 ./symfony project:permissions ### ~`project::send-emails`~ -`project::send-emails` タスクはキューに保存されるメールを送信する: +`project::send-emails` タスクはキューに保存されているメールを送信します。 - $ php symfony project:send-emails [--application[="..."]] [--env="..."] [--message-limit[="..."]] [--time-limit[="..."]] + $ php symfony project:send-emails [--application[="..."]] [--env="..."] [--message-limit[="..."]] [--time-limit[="..."]] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | -------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 @@ -1684,23 +1686,23 @@ Web サイトでホストされている PEAR パッケージをインストー | `--time-limit` | `0` | メッセージ送信の時間制限 (秒単位) -`project:send-emails` はキューに保存するメールを送信します: +`project:send-emails` はキューに保存されているメールを送信します。 php symfony project:send-emails -送信するメッセージの数を制限できます: +送信するメッセージの数を制限できます。 php symfony project:send-emails --message-limit=10 -もしくは時間を制限できます (秒単位): +もしくは秒単位で時間制限できます。 php symfony project:send-emails --time-limit=10 ### ~`project::validate`~ -`project::validate` タスクはプロジェクトのなかで使われている廃止予定の機能を見つける: +`project::validate` タスクはプロジェクトのなかで使われている廃止予定の機能を見つけます。 - $ php symfony project:validate + $ php symfony project:validate @@ -1712,50 +1714,50 @@ Web サイトでホストされている PEAR パッケージをインストー ./symfony project:validate -このタスクは symfony 1.4 に切り替える前に変更する必要のあるすべてのファイルの一覧を表示します。 +このタスクは symfony 1.4 に切り替える前に修正する必要のあるすべてのファイルの一覧を表示します。 `propel` -------- ### ~`propel::build`~ -`propel::build` タスクはスキーマに対応するコードを生成する: +`propel::build` タスクはスキーマに対応したコードを生成します。 - $ php symfony propel:build [--application[="..."]] [--env="..."] [--no-confirmation] [--all] [--all-classes] [--model] [--forms] [--filters] [--sql] [--db] [--and-load[="..."]] [--and-append[="..."]] + $ php symfony propel:build [--application[="..."]] [--env="..."] [--no-confirmation] [--all] [--all-classes] [--model] [--forms] [--filters] [--sql] [--db] [--and-load[="..."]] [--and-append[="..."]] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ------------------- | ----- | -------------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 | `--no-confirmation` | `-` | データベースの削除を強制するか -| `--all` | `-` | すべてをビルドしてデータベースをリセットする -| `--all-classes` | `-` | すべてのクラスをビルドする -| `--model` | `-` | モデルクラスをビルドする -| `--forms` | `-` | フォームクラスをビルドする -| `--filters` | `-` | フィルタクラスをビルドする -| `--sql` | `-` | SQL をビルドする -| `--db` | `-` | SQL を削除、作成、および挿入する -| `--and-load` | `-` | フィクスチャデータをロードする (複数の値が可能) -| `--and-append` | `-` | フィクスチャデータを追加する (複数の値が可能) +| `--all` | `-` | すべてをビルドしてデータベースをリセットします +| `--all-classes` | `-` | すべてのクラスをビルドします +| `--model` | `-` | モデルクラスをビルドします +| `--forms` | `-` | フォームクラスをビルドします +| `--filters` | `-` | フィルタクラスをビルドします +| `--sql` | `-` | SQL をビルドします +| `--db` | `-` | SQL を削除、作成、および挿入します +| `--and-load` | `-` | フィクスチャデータをロードします (複数の値が可能です) +| `--and-append` | `-` | フィクスチャデータを追加します (複数の値が可能です) -`propel:build` タスクはスキーマに対応するコードを生成します: +`propel:build` タスクはスキーマに対応したコードを生成します。 ./symfony propel:build -ビルドしたいものを指定しなければなりません。たとえば、モデルとフォームをビルドしたいのであれば、`--model` と `--forms` オプションをつけます: +ビルドしたいものを指定しなければなりません。たとえば、モデルとフォームをビルドしたいのであれば、`--model` と `--forms` オプションをつけます。 ./symfony propel:build --model --forms -すべてのクラスと SQL ファイルを生成してデータベースを再構築したいのであれば、ショートカットの `--all` オプションをつけます: +すべてのクラスと SQL ファイルを生成してデータベースを再構築したいのであれば、ショートカットの `--all` オプションをつけます。 ./symfony propel:build --all -このタスクは次のタスクの組み合わせと同じです: +このタスクは次のタスクの組み合わせと同じです。 ./symfony propel:build-model ./symfony propel:build-forms @@ -1763,47 +1765,47 @@ Web サイトでホストされている PEAR パッケージをインストー ./symfony propel:build-sql ./symfony propel:insert-sql -ショートカットの `--all-classes` オプションをつければ、クラスファイルだけを生成することもできます。このオプションを単独で指定するとき、データベースは修正されません。 +ショートカットの `--all-classes` オプションをつけると、クラスファイルだけが生成されます。このオプションを単独でつければ、データベースは修正されません。 ./symfony propel:build --all-classes -`--and-load` オプションをつけると、プロジェクトとプラグインの `data/fixtures/` ディレクトリからデータがロードされます: +`--and-load` オプションをつけると、プロジェクトとプラグインの `data/fixtures/` ディレクトリからデータがロードされます。 ./symfony propel:build --db --and-load -ロードするフィクスチャを指定するには、`--and-load` オプションにパラメータを渡します: +指定したフィクスチャをロードの対象に加えるには、`--and-load` オプションにフィクスチャのパスを渡します。 ./symfony propel:build --all --and-load="data/fixtures/dev/" -データベースのレコードを削除せずにフィクスチャデータを追加するには、`--and-append` オプションをつけます: +データベースのレコードを削除せずにフィクスチャのデータを追加するには、`--and-append` オプションをつけます。 ./symfony propel:build --all --and-append ### ~`propel::build-all`~ -`propel::build-all` タスクは Propel モデルとフォームクラス、SQL を生成しデータベースを初期化する: +`propel::build-all` タスクは Propel に対応したモデルとフォームクラス、SQL を生成しデータベースを初期化します。 - $ php symfony propel:build-all [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [-F|--skip-forms] [-C|--classes-only] [--phing-arg="..."] + $ php symfony propel:build-all [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [-F|--skip-forms] [-C|--classes-only] [--phing-arg="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ----------------------------- | ---------- | ------------------------------ | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 | `--connection` | `propel` | コネクションの名前 -| `--no-confirmation` | `-` | 確認メッセージを省略する -| `--skip-forms`
`(-F)` | `-` | フォーム生成を省略する -| `--classes-only`
`(-C)` | `-` | データベースを初期化しない -| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能) +| `--no-confirmation` | `-` | 確認メッセージを省略します +| `--skip-forms`
`(-F)` | `-` | フォーム生成を省略します +| `--classes-only`
`(-C)` | `-` | データベースを初期化しません +| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能です) -`propel:build-all` タスクはほかの5つのタスクのショートカットです: +`propel:build-all` タスクはほかの5つのタスクのショートカットです。 ./symfony propel:build-all -このタスクは次のタスクの組み合わせと同じです: +このタスクは次のタスクの組み合わせと同じです。 ./symfony propel:build-model ./symfony propel:build-forms @@ -1811,65 +1813,65 @@ Web サイトでホストされている PEAR パッケージをインストー ./symfony propel:build-sql ./symfony propel:insert-sql -詳しい情報はこれらのタスクのヘルプページを参照してください。 +くわしい説明はこれらのタスクのヘルプページをご参照ください。 -確認メッセージを省略するには、`no-confirmation` オプションをつけます: +確認メッセージを省略するには、`--no-confirmation` オプションをつけます。 ./symfony propel:buil-all --no-confirmation -すべてのクラスをビルドするがデータベースの初期化を省略するには、`classes-only` オプションをつけます: +すべてのクラスをビルドする際にデータベースの初期化を省略するには、`--classes-only` オプションをつけます。 ./symfony propel:build-all --classes-only ### ~`propel::build-all-load`~ -`propel::build-all-load` タスクは Propel モデルとフォームクラス、SQL を生成し、データベースを初期化し、データをロードする: +`propel::build-all-load` タスクは Propel に対応したモデルとフォームクラス、SQL を生成し、データベースを初期化し、データをロードします。 - $ php symfony propel:build-all-load [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [-F|--skip-forms] [-C|--classes-only] [--phing-arg="..."] [--append] [--dir="..."] + $ php symfony propel:build-all-load [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [-F|--skip-forms] [-C|--classes-only] [--phing-arg="..."] [--append] [--dir="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ---------- | --------------------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `dev` | 環境 | `--connection` | `propel` | コネクションの名前 -| `--no-confirmation` | `-` | 確認メッセージを省略する -| `--skip-forms`
`(-F)` | `-` | フォーム生成を省略する -| `--classes-only`
`(-C)` | `-` | データベースを初期化しない -| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能) -| `--append` | `-` | データベースの現在の値を削除しない -| `--dir` | `-` | フィクスチャを探すディレクトリ (複数の値が可能) +| `--no-confirmation` | `-` | 確認メッセージを省略します +| `--skip-forms`
`(-F)` | `-` | フォーム生成を省略します +| `--classes-only`
`(-C)` | `-` | データベースを初期化しません +| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能です) +| `--append` | `-` | データベースの現在の値を削除しません +| `--dir` | `-` | フィクスチャを探すディレクトリ (複数の値が可能です) -`propel:build-all-load` タスクはほかの2つのタスクのショートカットです: +`propel:build-all-load` タスクはほかの2つのタスクのショートカットです。 ./symfony propel:build-all-load -このタスクは次の2つのタスクの組み合わせと同じです: +このタスクは次の2つのタスクの組み合わせと同じです。 ./symfony propel:build-all ./symfony propel:data-load -詳しい情報はこれらのタスクのヘルプページを参照してください。 +くわしい説明はこれらのタスクのヘルプページをご参照ください。 -確認メッセージを省略するには、`no-confirmation` オプションをつけます: +確認メッセージを省略するには、`--no-confirmation` オプションをつけます。 ./symfony propel:buil-all-load --no-confirmation ### ~`propel::build-filters`~ -`propel::build-filters` タスクは現在のモデルに対応するフィルタフォームクラスを作る: +`propel::build-filters` タスクは現在のモデルに対応したフィルタフォームクラスを作ります。 - $ php symfony propel:build-filters [--connection="..."] [--model-dir-name="..."] [--filter-dir-name="..."] [--application[="..."]] [--generator-class="..."] + $ php symfony propel:build-filters [--connection="..."] [--model-dir-name="..."] [--filter-dir-name="..."] [--application[="..."]] [--generator-class="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ------------------- | ---------- | ------------------------------------ | `--connection` | `propel` | コネクションの名前 | `--model-dir-name` | `model` | モデルディレクトリ名 @@ -1878,31 +1880,31 @@ Web サイトでホストされている PEAR パッケージをインストー | `--generator-class` | `sfPropelFormFilterGenerator` | ジェネレータクラス -`propel:build-filters` タスクはスキーマからフィルタフォームクラスを作ります: +`propel:build-filters` タスクはスキーマからフィルタフォームクラスを作ります。 ./symfony propel:build-filters -このタスクはプロジェクトとインストール済みのすべてのプラグインから `config/*schema.xml` かつ/もしくは `config/*schema.yml` のスキーマ情報を読み込みます。 +このタスクはプロジェクトとインストールずみのすべてのプラグインから `config/` ディレクトリの `*schema.xml` かつ/もしくは `*schema.yml` ファイルの情報を読み込みます。 -このタスクは `config/databases.yml` で定義されている `propel` コネクションを利用します。`--connection` オプションを指定すれば、別のコネクションを利用することができます: +このタスクは `config/` ディレクトリの `databases.yml` ファイルのなかで定義されている `propel` コネクションを利用します。`--connection` オプションを指定すれば、別のコネクションを利用することができます。 ./symfony propel:build-filters --connection="name" -モデルのフィルタフォームクラスは `lib/filter` に作られます。 +モデルのフィルタフォームクラスは `lib/filter/` ディレクトリに作られます。 -このタスクは `lib/filter` のなかのカスタムクラスを上書きすることはけっしてありません。このタスクは `lib/filter/base` に生成された基底クラスを置き換えます。 +このタスクは `lib/filter/` ディレクトリのなかのカスタムクラスを上書きすることはけっしてありません。このタスクは `lib/filter/base/` ディレクトリに生成された基底クラスを置き換えます。 ### ~`propel::build-forms`~ -`propel::build-forms` タスクは現在のモデルに対応するフォームクラスを作る: +`propel::build-forms` タスクは現在のモデルに対応したフォームクラスを作ります。 - $ php symfony propel:build-forms [--connection="..."] [--model-dir-name="..."] [--form-dir-name="..."] [--application[="..."]] [--generator-class="..."] + $ php symfony propel:build-forms [--connection="..."] [--model-dir-name="..."] [--form-dir-name="..."] [--application[="..."]] [--generator-class="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ---------- | -------------------------- | `--connection` | `propel` | コネクションの名前 | `--model-dir-name` | `model` | モデルディレクトリの名前 @@ -1911,71 +1913,71 @@ Web サイトでホストされている PEAR パッケージをインストー | `--generator-class` | `sfPropelFormGenerator` | ジェネレータクラス -`propel:build-forms` タスクはスキーマからフォームクラスを作ります: +`propel:build-forms` タスクはスキーマからフォームクラスを作ります。 ./symfony propel:build-forms -このタスクはプロジェクトとインストール済みのすべてのプラグインから `config/*schema.xml` かつ/もしくは `config/*schema.yml` のスキーマ情報を読み込みます。 +このタスクはプロジェクトとインストールずみのすべてのプラグインから `config/` ディレクトリの `*schema.xml` かつ/もしくは `*schema.yml` ファイルの情報を読み込みます。 -このタスクは `config/databases.yml` で定義されている `propel` コネクションを利用します。`--connection` オプションを指定すれば、別のコネクションを利用することができます: +このタスクは `config/` ディレクトリの `databases.yml` ファイルのなかで定義されている `propel` コネクションを利用します。`--connection` オプションを指定すれば、別のコネクションを利用できます。 ./symfony propel:build-forms --connection="name" -モデルのフォームクラスは `lib/form` に作られます。 +モデルのフォームクラスは `lib/form/` ディレクトリに作られます。 -このタスクは `lib/form` のカスタムクラスを上書きすることはありません。このタスクは `lib/form/base` に生成された基底クラスのみを置き換えます。 +このタスクは `lib/form/` ディレクトリのカスタムクラスを上書きすることはありません。このタスクは `lib/form/base/` ディレクトリに生成された基底クラスのみを置き換えます。 ### ~`propel::build-model`~ -`propel::build-model` タスクは現在のモデルに対応するクラスを作る: +`propel::build-model` タスクは現在のモデルに対応したクラスを作ります。 - $ php symfony propel:build-model [--phing-arg="..."] + $ php symfony propel:build-model [--phing-arg="..."] -| オプション (ショートカット) | デフォルト | 説明 -| -------------------------- | ---------- | ----------------------------------- -| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能) +| オプション (ショートカット) | デフォルト | 説明 +| -------------------------- | ---------- | ---------------------------------------- +| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能です) -`propel:build-model` タスクはスキーマからモデルクラスを作ります: +`propel:build-model` タスクはスキーマからモデルクラスを作ります。 ./symfony propel:build-model -このタスクはプロジェクトとインストール済みのすべてのプラグインから `config/*schema.xml` かつ/もしくは `config/*schema.yml` のスキーマ情報を読み込みます。 +このタスクはプロジェクトとインストールずみのすべてのプラグインから `config/` ディレクトリの `*schema.xml` かつ/もしくは `*schema.yml` ファイルの情報を読み込みます。 -YAML と XML スキーマファイルを混ぜることができます。このタスクは Propel タスクを呼び出す前に YAML を XML に変換します。 +YAML と XML ファイルを組み合わせることができます。このタスクは Propel タスクを呼び出す前に YAML を XML に変換します。 -モデルクラスのファイルは `lib/model` に作られます。 +モデルクラスのファイルは `lib/model/` ディレクトリに作られます。 -このタスクは `lib/model` のなかのカスタムクラスを置き換えることはけっしてありません。このタスクは`lib/model/om` と `lib/model/map` のファイルのみを置き換えます。 +このタスクは `lib/model/` ディレクトリのなかのカスタムクラスを置き換えることはけっしてありません。このタスクは `lib/model/om/` と `lib/model/map/` ディレクトリの下にあるファイルだけを置き換えます。 ### ~`propel::build-schema`~ -`propel::build-schema` タスクは既存のデータベースからスキーマを作る: +`propel::build-schema` タスクは既存のデータベースからスキーマを作ります。 - $ php symfony propel:build-schema [--application[="..."]] [--env="..."] [--connection="..."] [--xml] [--phing-arg="..."] + $ php symfony propel:build-schema [--application[="..."]] [--env="..."] [--connection="..."] [--xml] [--phing-arg="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | ---------- | -------------------------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `cli` | 環境 | `--connection` | `-` | コネクションの名前 -| `--xml` | `-` | YAML の代わりに XML スキーマを作る -| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能) +| `--xml` | `-` | YAML の代わりに XML スキーマを作ります +| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能です) -`propel:build-schema` タスクはスキーマを作るためにデータベースをイントロスペクトします: +`propel:build-schema` タスクはデータベースをイントロスペクトしてスキーマを作ります。 ./symfony propel:build-schema -デフォルトでは、このタスクは YAML ファイルを作りますが、XML ファイルも作ることができます: +デフォルトでは、このタスクは YAML ファイルを作りますが、XML ファイルも作ることができます。 ./symfony --xml propel:build-schema @@ -1983,30 +1985,30 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 ### ~`propel::build-sql`~ -`propel::build-sql` タスクは現在のモデルに対応する SQL を生成する: +`propel::build-sql` タスクは現在のモデルに対応した SQL ファイルを生成します。 - $ php symfony propel:build-sql [--phing-arg="..."] + $ php symfony propel:build-sql [--phing-arg="..."] -| オプション (ショートカット) | デフォルト | 説明 -| ---------------------------- | ---------- | ----------------------------------- -| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能) +| オプション (ショートカット) | デフォルト | 説明 +| ---------------------------- | ---------- | ---------------------------------------- +| `--phing-arg` | `-` | Phing の任意の引数 (複数の値が可能です) -`propel:build-sql` タスクはテーブル作成の SQL 文を生成します: +`propel:build-sql` タスクはテーブル作成の SQL ファイルを生成します。 ./symfony propel:build-sql -生成される SQL は `config/propel.ini`で指定されているデータベースに合わせて最適化されます: +生成される SQL ファイルは `config/` ディレクトリの `propel.ini` ファイルのなかで指定されているデータベースに合わせて最適化されます。 propel.database = mysql ### ~`propel::data-dump`~ -`propel::data-dump` タスクはデータをフィクスチャディレクトリに吐き出す: +`propel::data-dump` タスクはデータをフィクスチャディレクトリに吐き出します。 $ php symfony propel:data-dump [--application[="..."]] [--env="..."] [--connection="..."] [--classes="..."] [target] @@ -2017,84 +2019,84 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `target` | `-` | ターゲットのファイル名 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | --------------------------- | ---------- | ------------------------------------------ | `--application` | `1` | アプリケーションの名前 | `--env` | `cli` | 環境 | `--connection` | `propel` | コネクションの名前 -| `--classes` | `-` | 吐き出すクラスの名前 (コロンで区切られる) +| `--classes` | `-` | 吐き出されるクラスの名前 (コロンで区切られます) -`propel:data-dump` タスクはデータベースデータを吐き出します: +`propel:data-dump` タスクはデータベースデータを吐き出します。 ./symfony propel:data-dump > data/fixtures/dump.yml -デフォルトでは、タスクはデータを標準出力しますが、第2引数にファイルの名前を渡すこともできます: +デフォルトでは、データは標準出力されますが、ファイルの名前を第2引数に渡すこともできます。 ./symfony propel:data-dump dump.yml -上記の例では、データが `data/fixtures/%target%` に吐き出されます (この例では `data/fixtures/dump.yml`)。 +上記の例では、データは `data/fixtures/%target%/` ディレクトリに吐き出されます (この例では `data/fixtures/dump.yml`)。 -`propel:data-load` タスクを使うことで、吐き出されたファイルを YAML フォーマットで再インポートできます。 +`propel:data-load` タスクを使えば、吐き出されたファイルを YAML フォーマットで再インポートできます。 -デフォルトでは、`config/databases.yml` で定義されている `propel` コネクションを利用します。`connection` オプションを指定すれば、別のコネクションを利用することができます: +デフォルトでは、`config/` ディレクトリの `databases.yml` ファイルのなかで定義されている `propel` コネクションが利用されます。`--connection` オプションを指定すれば、別のコネクションを利用できます。 ./symfony propel:data-dump --connection="name" -クラスだけを吐き出させたいのであれば、`classes` オプションを指定します: +クラスだけを吐き出させたいのであれば、`--classes` オプションを指定します。 ./symfony propel:data-dump --classes="Article,Category" -アプリケーションから特定のデータベースコネクションを利用したければ、`application` オプションを指定します: +アプリケーションから特定のデータベースコネクションを利用したければ、`--application` オプションを指定します。 ./symfony propel:data-dump --application=frontend ### ~`propel::data-load`~ -`propel::data-load` タスクは YAML フィクスチャデータをロードする: +`propel::data-load` タスクは YAML フィクスチャのデータをロードします。 $ php symfony propel:data-load [--application[="..."]] [--env="..."] [--append] [--connection="..."] [dir_or_file1] ... [dir_or_fileN] | 引数 | デフォルト | 説明 -| ---- | ------------ | ---------------------------------------- -| `dir_or_file` | `-` | ロードするディレクトリもしくはファイル +| ---- | ------------ | ---------------------------------------------- +| `dir_or_file` | `-` | ロードの対象となるディレクトリもしくはファイル -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ----------- | ----------- | `--application` | `1` | アプリケーションの名前 | `--env` | `cli` | 環境 -| `--append` | `-` | データベースの現在のデータを削除しない +| `--append` | `-` | データベースの現在のデータを削除しません | `--connection` | `propel` | コネクションの名前 -`propel:data-load` タスクはデーターベースにデータフィクスチャをロードさせます: +`propel:data-load` タスクはデーターベースにデータフィクスチャをロードさせます。 ./symfony propel:data-load -`data/fixtures/` で見つかるすべてのファイルからデータがロードされます。 +`data/fixtures/` で配置されているすべてのファイルからデータがロードされます。 -特定のファイルもしくはディレクトリからデータをロードさせたいのであれば、引数にこれらを渡します: +ロードの対象となるファイルもしくはディレクトリを指定したいのであれば、引数にこれらのパスを渡します。 ./symfony propel:data-load data/fixtures/dev data/fixtures/users.yml -このタスクは `config/databases.yml` で定義されている `propel` コネクションを利用します。`--connection` オプションを指定すれば、別のコネクションを利用することができます: +このタスクは `config/` ディレクトリの `databases.yml` ファイルのなかで定義されている `propel` コネクションを利用します。`--connection` オプションを指定すれば、別のコネクションを利用できます。 ./symfony propel:data-load --connection="name" -データベースのなかの既存のデータを削除したくなければ、`--append` オプションをつけます: +データベースのなかの既存のデータを削除したくなければ、`--append` オプションをつけます。 ./symfony propel:data-load --append -アプリケーションから特定のデータベースコンフィギュレーションを使いたければ、`application` オプションを指定します: +アプリケーションから特定のデータベースコンフィギュレーションを使いたければ、`--application` オプションを指定します。 ./symfony propel:data-load --application=frontend ### ~`propel::generate-admin`~ -`propel::generate-admin` タスクは Propel アドミンモジュールを生成する: +`propel::generate-admin` タスクは Propel に対応したアドミンモジュールを生成します。 $ php symfony propel:generate-admin [--module="..."] [--theme="..."] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route_or_model @@ -2106,7 +2108,7 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `route_or_model` | `-` | ルートの名前もしくはモデルクラス -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ----------------- | ------- | ------------------- | `--module` | `-` | モジュールの名前 | `--theme` | `admin` | テーマの名前 @@ -2116,31 +2118,31 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `--actions-base-class` | `sfActions` | アクションの基底クラス -`propel:generate-admin` タスクは Propel アドミンモジュールを生成します: +`propel:generate-admin` タスクは Propel に対応したアドミンモジュールを生成します。 ./symfony propel:generate-admin frontend Article -上記の例では、`%frontend%` アプリケーションのなかで `%Article%` モデルに対応するモジュールが生成されます。 +上記の例では、`%Article%` モデルに対応したモジュールが `%frontend%` アプリケーションに生成されます。 -このタスクはあなたに代わってアプリケーションの `routing.yml` でルートを作ります。 +このタスクはあなたに代わってアプリケーションの `routing.yml` ファイルにルートを作ります。 -ルートの名前を渡すことで、Propel アドミンモジュールを生成することもできます: +ルートの名前を引数に渡せば、Propel に対応したアドミンモジュールを生成することもできます。 ./symfony propel:generate-admin frontend article -上記の例では、`%frontend%` アプリケーションのなかで `routing.yml` の `%article%` に対応するモジュールが生成されます。 +上記の例では、`%frontend%` アプリケーションのなかで `routing.yml` ファイルの `%article%` に対応したモジュールが生成されます。 -フィルタとバッチアクションが適切に動くようにするには、ルートのコンフィギュレーションのなかで `with_wildcard_routes` オプションを指定する必要があります: +フィルタとバッチアクションがきちんと動くようにするには、ルートのコンフィギュレーションのなかで `with_wildcard_routes` オプションに `true` をセットする必要があります。 article: - class: sfPropelRouteCollection - options: - model: Article - with_wildcard_routes: true + class: sfPropelRouteCollection + options: + model: Article + with_wildcard_routes: true ### ~`propel::generate-module`~ -`propel::generate-module` タスクは Propel モジュールを生成する: +`propel::generate-module` タスクは Propel に対応したモジュールを生成します。 $ php symfony propel:generate-module [--theme="..."] [--generate-in-cache] [--non-verbose-templates] [--with-show] [--singular="..."] [--plural="..."] [--route-prefix="..."] [--with-propel-route] [--env="..."] [--actions-base-class="..."] application module model @@ -2153,43 +2155,43 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `model` | `-` | モデルクラスの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | --------------------------- | ---------- | ----------- | `--theme` | `default` | テーマの名前 -| `--generate-in-cache` | `-` | キャッシュでモジュールを生成する -| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成する -| `--with-show` | `-` | show メソッドを生成する +| `--generate-in-cache` | `-` | モジュールをキャッシュに生成します +| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成します +| `--with-show` | `-` | show メソッドを生成します | `--singular` | `-` | 単数形の名前 | `--plural` | `-` | 複数形の名前 | `--route-prefix` | `-` | ルートのプレフィックス | `--with-propel-route` | `-` | Propel ルートを使うかどうか | `--env` | `dev` | 環境 -| `--actions-base-class` | `sfActions` | アクションの既定クラス +| `--actions-base-class` | `sfActions` | アクションの基底クラス -`propel:generate-module` タスクは Propel モジュールを生成します: +`propel:generate-module` タスクは Propel に対応したモジュールを生成します。 ./symfony propel:generate-module frontend article Article -上記の例では、`%application%` アプリケーションのなかで `%model%` モデルクラスに対応する `%module%` モジュールが生成されます。 +上記の例では、`%model%` モデルクラスに対応した `%module%` モジュールが `%application%` アプリケーションに生成されます。 -`--generate-in-cache` オプションを指定すれば、実行時に生成されるモジュールからアクションとテンプレートを継承する空のモジュールを `%sf_app_cache_dir%/modules/auto%module%` のなかで作ることもできます: +`--generate-in-cache` オプションを指定すれば、実行時に生成されるモジュールからアクションとテンプレートを継承した空のモジュールが `%sf_app_cache_dir%/modules/auto%module%/` ディレクトリに作られます。 ./symfony propel:generate-module --generate-in-cache frontend article Article -`--theme` オプションを指定すれば、ジェネレータはカスタマイズ済みのテーマを使います: +`--theme` オプションを指定すれば、カスタマイズずみのテーマが使われます。 ./symfony propel:generate-module --theme="custom" frontend article Article -この方法では、独自の慣習に合わせてモジュールジェネレータを作ることができます。 +この方法では、自分のスタイルに合わせてモジュールジェネレータを作ることができます。 -生成モジュールに使われるデフォルトの基底クラス (sfActions) を変更することもできます: +`--actions-base-class` オプションを指定すれば、生成モジュールに使われるデフォルトの基底クラス (sfActions) を変更することもできます。 ./symfony propel:generate-module --actions-base-class="ProjectActions" frontend article Article ### ~`propel::generate-module-for-route`~ -`propel::generate-module-for-route` タスクはルート定義に対応する Propel モジュールを生成する: +`propel::generate-module-for-route` タスクは Propel のルート定義に対応したモジュールを生成します。 $ php symfony propel:generate-module-for-route [--theme="..."] [--non-verbose-templates] [--singular="..."] [--plural="..."] [--env="..."] [--actions-base-class="..."] application route @@ -2201,81 +2203,81 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `route` | `-` | ルートの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ----------------- | -------- | ----------------- | `--theme` | `default` | テーマの名前 -| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成する +| `--non-verbose-templates` | `-` | 冗長ではないテンプレートを生成します | `--singular` | `-` | 単数形の名前 | `--plural` | `-` | 複数形の名前 | `--env` | `dev` | 環境 | `--actions-base-class` | `sfActions` | アクションの基底クラス -`propel:generate-module-for-route` タスクはルート定義に対応する Propel モジュールを生成します: +`propel:generate-module-for-route` タスクは Propel のルート定義に対応したモジュールを生成します。 ./symfony propel:generate-module-for-route frontend article -上記の例では、`%frontend%` アプリケーションのなかで `routing.yml` の `%article%` ルート定義に対応するモジュールが生成されます。 +上記の例では、`routing.yml` ファイルの `%article%` ルートに対応したモジュールが `%frontend%` アプリケーションに生成されます。 ### ~`propel::graphviz`~ -`propel::graphviz` タスクは現在のオブジェクトモデルに対応する Graphviz チャートを生成する: +`propel::graphviz` タスクは現在のオブジェクトモデルに対応した Graphviz チャートを生成します。 - $ php symfony propel:graphviz [--phing-arg="..."] + $ php symfony propel:graphviz [--phing-arg="..."] -| オプション (ショートカット) | デフォルト | 説明 -| ----------------- | ------- | ----------- -| `--phing-arg` | `-` | 任意の Phing 引数 (複数の値が可能) +| オプション (ショートカット) | デフォルト | 説明 +| ----------------- | ------- | ------------------------------ +| `--phing-arg` | `-` | 任意の Phing 引数 (複数の値が可能です) -`propel:graphviz` タスクは、オブジェクトモデルの自動グラフ描画のために Graphviz の DOT 可視化画像を生成します: +`propel:graphviz` タスクは、オブジェクトモデルの自動グラフ描画のために Graphviz の DOT 可視化画像を生成します。 ./symfony propel:graphviz ### ~`propel::insert-sql`~ -`propel::insert-sql` タスクは現在のモデルに対応するテーブルを作る: +`propel::insert-sql` タスクは現在のモデルに対応したテーブルを作ります。 - $ php symfony propel:insert-sql [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [--phing-arg="..."] + $ php symfony propel:insert-sql [--application[="..."]] [--env="..."] [--connection="..."] [--no-confirmation] [--phing-arg="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ----------------- | ------- | ------------------- | `--application` | `1` | アプリケーションの名前 | `--env` | `cli` | 環境 | `--connection` | `-` | コネクションの名前 -| `--no-confirmation` | `-` | 確認メッセージを省略する -| `--phing-arg` | `-` | 任意の Phing 引数 (複数の値が可能) +| `--no-confirmation` | `-` | 確認メッセージを省略します +| `--phing-arg` | `-` | 任意の Phing 引数 (複数の値が可能です) -`propel:insert-sql` タスクはデータベースのテーブルを作ります: +`propel:insert-sql` タスクはデータベースのテーブルを作ります。 ./symfony propel:insert-sql -このタスクはデータベースコネクションを確立し、`config/sql/*schema.sql` ファイルで見つかるすべての SQL 文を実行します。 +このタスクはデータベースに接続し、`config/sql/` ディレクトリの `*schema.sql` ファイルのなかで見つかるすべての SQL 文を実行します。 -このタスクは実行前にデータベースのすべてのデータを削除するので、本当に実行するかどうか確認を求めてきます。 +このタスクは実行前にデータベースのデータをすべて削除するので、本当に実行するかどうかたずねてきます。 -確認メッセージを省略するには、`--no-confirmation` オプションをつけます: +確認メッセージを省略するには、`--no-confirmation` オプションをつけます。 ./symfony propel:insert-sql --no-confirmation -このタスクは `databases.yml` からデータベースのコンフィギュレーションを読み込みます。`--application` もしくは `--env` オプションを指定すれば、特定のアプリケーション/環境を利用することができます。 +このタスクは `databases.yml` ファイルからデータベースのコンフィギュレーションを読み込みます。`--application` もしくは `--env` オプションを指定すれば、特定のアプリケーション/環境を利用することができます。 -任意のコネクションで SQL 文だけを読み込ませたいのであれば、`--connection` オプションを指定することもできます。 +任意のコネクションで SQL 文だけを読み込ませたいのであれば、`--connection` オプションを指定します。 ### ~`propel::schema-to-xml`~ -`propel::schema-to-xml` タスクは schema.yml から schema.xml を作る: +`propel::schema-to-xml` タスクは schema.yml ファイルから schema.xml ファイルを作ります。 - $ php symfony propel:schema-to-xml + $ php symfony propel:schema-to-xml @@ -2283,15 +2285,15 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 -`propel:schema-to-xml` タスクは YAML スキーマを XML に変換します: +`propel:schema-to-xml` タスクは YAML スキーマを XML に変換します。 ./symfony propel:schema-to-xml ### ~`propel::schema-to-yml`~ -`propel::schema-to-yml` タスクは schema.xml から creates schema.yml を作る: +`propel::schema-to-yml` タスクは `schema.xml` ファイルから `schema.yml` ファイルを作ります。 - $ php symfony propel:schema-to-yml + $ php symfony propel:schema-to-yml @@ -2299,7 +2301,7 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 -`propel:schema-to-yml` タスクは XML スキーマを YAML に変換します: +`propel:schema-to-yml` タスクは XML スキーマを YAML に変換します。 ./symfony propel:schema-to-yml @@ -2308,23 +2310,23 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 ### ~`symfony::test`~ -`symfony::test`タスクは symfony テストスイートを実行する: +`symfony::test`タスクはテストスイートを実行します。 - $ php symfony symfony:test [-u|--update-autoloader] [-f|--only-failed] [--xml="..."] [--rebuild-all] + $ php symfony symfony:test [-u|--update-autoloader] [-f|--only-failed] [--xml="..."] [--rebuild-all] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | --------------------------------- | --------- | ------------------------------------------- -| `--update-autoloader`
`(-u)` | `-` | sfCoreAutoload クラスを更新する -| `--only-failed`
`(-f)` | `-` | 最後に通らなかったテストだけを実行する +| `--update-autoloader`
`(-u)` | `-` | sfCoreAutoload クラスを更新します +| `--only-failed`
`(-f)` | `-` | 最後に通らなかったテストだけを実行します | `--xml` | `-` | JUnit と互換性のある XML ログファイルの名前 -| `--rebuild-all` | `-` | すべての生成フィクスチャファイルを再構築する +| `--rebuild-all` | `-` | すべての生成フィクスチャファイルを再構築します -`test:all` タスクは symfony テストスイートを実行します: +`test:all` タスクはテストスイートを実行します。 ./symfony symfony:test @@ -2333,45 +2335,45 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 ### ~`test::all`~ -`test::all` タスクはすべてのテストを実行する: +`test::all` タスクはすべてのテストを実行します。 - $ php symfony test:all [-f|--only-failed] [--xml="..."] + $ php symfony test:all [-f|--only-failed] [--xml="..."] -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | --------------------------- | ---------- | ------------------------------------------- -| `--only-failed`
`(-f)` | `-` | 最後に通らなかったテストだけを実行する +| `--only-failed`
`(-f)` | `-` | 最後に通らなかったテストだけを実行します | `--xml` | `-` | JUnit と互換性のある XML ログファイルの名前 -`test:all` タスクはすべてのユニットテストと機能テストを実行します: +`test:all` タスクはすべてのユニットテストと機能テストを実行します。 ./symfony test:all このタスクは `test/` で見つかるすべてのテストを実行します。 -テストの一部が通らない場合に関する詳しい情報を表示するには、`--trace` オプションをつけます: +`--trace` オプションをつければ、テストの一部が通らない場合にくわしい説明が表示されます。 ./symfony test:all -t -もしくはこれらのテストスイートを `test:unit` と `test:functional` タスクで実行することで、問題の対応にとりかかることもできます。 +もしくはこれらのテストスイートを `test:unit` と `test:functional` タスクで実行することで、問題の解決にとりかかることもできます。 -以前の実行のときに通らなかったテストだけを実行するように強制させるには、`--only-failed` オプションをつけます: +`--only-failed` オプションをつければ、以前の実行のときに通らなかったテストだけを実行するように強制させることができます。 ./symfony test:all --only-failed -どのように動くのかは次のとおりです: 最初に、通常のようにすべてのテストが実行されます。しかしその後実行されるテストでは、前回通らなかったテストのみが実行されます。コードの修正作業が進むにつれて、テストの一部が通るようになり、その後の実行から除外されるようになります。すべてのテストが通るようになったとき、フルテストスイートが実行され、徹底的に繰り返すことができます。 +どのように動くのかを説明します。最初において、すべてのテストがいつものように実行されますが、それ以降では、前回通らなかったテストのみが実行されます。コードの修正作業が進むにつれて、テストの一部が通るようになり、その後の実行から除外されるようになります。すべてのテストが通るようになったとき、フルテストスイートが実行され、徹底的に繰り返すことができます。 -`--xml` オプションをつければ、JUnit と互換性のある XML ログファイルを出力できます: +`--xml` オプションをつけると、JUnit と互換性のある XML ログファイルが出力されます。 ./symfony test:all --xml=log.xml ### ~`test::coverage`~ -`test::coverage` タスクはテストのコードカバレッジを出力する: +`test::coverage` タスクはテストのコードカバレッジを出力します。 $ php symfony test:coverage [--detailed] test_name lib_name @@ -2380,25 +2382,25 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | 引数 | デフォルト | 説明 | ----------- | ---------- | -------------------------------------------------------------- | `test_name` | `-` | テストファイルの名前もしくはテストのディレクトリ -| `lib_name` | `-` | カバレージを知りたい lib ファイルの名前もしくは lib ディレクトリ +| `lib_name` | `-` | カバレージを知りたいファイルの名前もしくは lib ディレクトリ -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | ---------- | -------------------- -| `--detailed` | `-` | 詳しい情報を出力する +| `--detailed` | `-` | くわしい説明を出力します -`test:coverage` タスクはテストディレクトリもしくはテストディレクトリかつ lib ファイルもしくは lib ディレクトリとしてコードカバレージを出力します: +`test:coverage` タスクは test ディレクトリまたは test ディレクトリと lib ファイルまたは lib ディレクトリとしてコードカバレージを出力します。 ./symfony test:coverage test/unit/model lib/model -カバーされていない行を出力するには、`--detailed` オプションを指定します: +`--detailed` オプションを指定すれば、カバーされていない行が出力されます。 ./symfony test:coverage --detailed test/unit/model lib/model ### ~`test::functional`~ -`test::functional` タスクは機能テストを実行する: +`test::functional` タスクは機能テストを実行します。 $ php symfony test:functional [--xml="..."] application [controller1] ... [controllerN] @@ -2410,36 +2412,36 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `controller` | `-` | コントローラの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | ---------------------------- | ----------- | --------------- | `--xml` | `-` | JUnit と互換性のある XML ログファイルの名前 -`test:functional` タスクは任意のアプリケーションに対する機能テストを実行します: +`test:functional` タスクは任意のアプリケーションに対して機能テストを実行します。 ./symfony test:functional frontend -このタスクは `test/functional/%application%` で見つかるすべてのテストを実行します。 +このタスクは `test/functional/%application%/` ディレクトリで見つかるすべてのテストを実行します。 -テストの一部が通らない場合に関する詳しい情報を表示するには、`--trace` オプションをつけます: +`--trace` オプションをつければ、テストの一部が通らない場合にくわしい説明が表示されます。 ./symfony test:functional frontend -t -コントローラの名前を渡せば、特定のコントローラに対するすべての機能テストを実行することができます: +コントローラの名前を渡せば、特定のコントローラに対するすべての機能テストを実行することができます。 ./symfony test:functional frontend article -複数のコントローラに対する機能テストをすべて実行することもできます: +複数のコントローラに対する機能テストをまとめて実行することもできます。 ./symfony test:functional frontend article comment -`--xml` オプションを指定すれば、JUnit と互換性のある XML ログファイルが出力されます: +`--xml` オプションを指定すると、JUnit と互換性のある XML ログファイルが出力されます。 ./symfony test:functional --xml=log.xml ### ~`test::unit`~ -`test::unit` タスクはユニットテストを実行する: +`test::unit` タスクはユニットテストを実行します。 $ php symfony test:unit [--xml="..."] [name1] ... [nameN] @@ -2450,33 +2452,32 @@ XML フォーマットは YAML よりも多くの情報を格納できます。 | `name` | `-` | テストの名前 -| オプション (ショートカット) | デフォルト | 説明 +| オプション (ショートカット) | デフォルト | 説明 | -------------------------- | --------- | ---------------------------- | `--xml` | `-` | JUnit と互換性のある XML ログファイルの名前 -`test:unit` タスクはユニットテストを実行します: +`test:unit` タスクはユニットテストを実行します。 ./symfony test:unit -このタスクは `test/unit` で見つかるすべてのテストを実行します。 +このタスクは `test/unit/` ディレクトリで見つかるすべてのテストを実行します。 -テストの一部が通らない場合に詳しい情報を表示するには、`--trace` オプションをつけます: +`--trace` オプションをつければ、テストの一部が通らない場合にくわしい説明が表示されます。 ./symfony test:unit -t -特定の名前のユニットテストを実行することができます: +特定のユニットテストを指名することができます。 ./symfony test:unit strtolower -複数の名前のユニットテストを実行することもできます: +複数のユニットテストをまとめて実行することもできます。 ./symfony test:unit strtolower strtoupper -`--xml` オプションを指定すれば、JUnit と互換性のある XML ログファイルを出力できます: +`--xml` オプションを指定すれば、JUnit と互換性のある XML ログファイルが出力されます。 ./symfony test:unit --xml=log.xml - diff --git a/tutorial/ja/deprecated.markdown b/tutorial/ja/deprecated.markdown index 703de32..24d0bbf 100644 --- a/tutorial/ja/deprecated.markdown +++ b/tutorial/ja/deprecated.markdown @@ -1,25 +1,25 @@ -1.3 で廃止予定になったもしくは削除された機能 -============================================== +1.3で廃止予定になったもしくは削除された機能 +============================================ -このドキュメントでは symfony 1.3 で廃止予定になったもしくは削除されたすべての設定、クラス、メソッド、関数とタスクをひととおり説明します。 +このドキュメントでは symfony 1.3 で廃止予定になったもしくは削除された設定、クラス、メソッド、関数とタスクをひととおり説明します。 コアプラグイン ------------- +-------------- -次のコアプラグインは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました: +次のコアプラグインは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。 - * `sfCompat10Plugin`: このプラグインが廃止予定になることで、このプラグインに依存するほかのすべての要素も廃止予定になりました (symfony 1.0 のアドミンジェネレータとフォームシステム)。これらのなかには、 `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置されているアドミンジェネレータのデフォルトテーマも含まれています。 + * `sfCompat10Plugin`: このプラグインが廃止予定になったことにともない、このプラグインに依存するほかのすべての要素も廃止予定になりました (symfony 1.0 のアドミンジェネレータとフォームシステム)。これらのなかには、 `lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` ディレクトリに配置されていたアドミンジェネレータのデフォルトテーマも含まれます。 - * `sfProtoculousPlugin`: このプラグインから提供されるヘルパーは控えめな JavaScript をサポートしないので、今後は使うべきではありません。 + * `sfProtoculousPlugin`: このプラグインから提供されるヘルパーは控えめな JavaScript をサポートしていないので、今後使うことはおすすめしません。 メソッドと関数 -------------- -次のメソッドと関数は symfony 1.3 もしくはそれ以前のバージョンで廃止予定になり、symfony 1.4 で削除されました: +次のメソッドと関数は symfony 1.3 もしくはそれ以前のバージョンで廃止予定になり、symfony 1.4 で削除されました。 - * `sfToolkit::getTmpDir()`: このメソッド呼び出しはすべて `sys_get_temp_dir()` に置き換えます。 + * `sfToolkit::getTmpDir()`: このメソッド呼び出しはすべて PHP の `sys_get_temp_dir()` 関数に置き換えます。 * `sfToolkit::removeArrayValueForPath()`、 `sfToolkit::hasArrayValueForPath()` と `getArrayValueForPathByRef()` @@ -32,65 +32,65 @@ * `sfTestFunctionalBase` の次のメソッド: `isRedirected()`、`isStatusCode()`、`responseContains()`、 `isRequestParameter()`、`isResponseHeader()`、 - `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは symfony 1.2 以降で廃止予定になったので、テスタークラスに置き換えます。 + `isUserCulture()`、`isRequestFormat()` と `checkResponseElement()`: これらのメソッドは symfony 1.2 以降で廃止予定になりましたので、テスタークラスに置き換えます。 - * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは symfony 1.2 以降で廃止予定になったので、テスタークラスに置き換えます。 + * `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは symfony 1.2 以降で廃止予定になりましたので、テスタークラスに置き換えます。 - * `sfFilesystem::sh()`: このメソッド呼び出しは新しい `sfFilesystem::execute()` メソッド呼び出しに置き換えます。このメソッドの戻り値は `stdout` 出力と `stderr` 出力で構成される配列であることにご注意ください。 + * `sfFilesystem::sh()`: このメソッド呼び出しは新しい `sfFilesystem::execute()` メソッド呼び出しに置き換えます。このメソッドの戻り値は `stdout` 出力と `stderr` 出力からなる配列であることにご注意ください。 * `sfAction::getDefaultView()`、`sfAction::handleError()`、 - `sfAction::validate()`: これらのメソッドは symfony 1.1 で廃止予定になり、またあまり役に立つものではありませんでした。symfony 1.1 で利用するには、`compat_10` 設定を `on` にセットする必要があります。 + `sfAction::validate()`: これらのメソッドはあまり役に立っていませんでしたので symfony 1.1 で廃止予定になりました。symfony 1.1 で利用するには、`compat_10` 設定に `on` をセットする必要があります。 * `sfComponent::debugMessage()`: 代わりに `log_message()` ヘルパーを使います。 - * `sfApplicationConfiguration::loadPluginConfig()`: 代わりに `initializePlugins()` を使います。 + * `sfApplicationConfiguration::loadPluginConfig()`: 代わりに `initializePlugins()` メソッドを使います。 - * `sfLoader::getHelperDirs()` と `sfLoader::loadHelpers()`: `sfApplicationConfiguration` オブジェクトから同じメソッドを使ってください。`sfLoader` クラスのメソッドがすべて廃止予定になったので、`sfLoader` は symfony 1.4 で削除されました。 + * `sfLoader::getHelperDirs()` と `sfLoader::loadHelpers()`: `sfApplicationConfiguration` オブジェクトから同じ名前のメソッドを使います。`sfLoader` クラスのメソッドがすべて廃止予定になったことを受けて、symfony 1.4 で `sfLoader` クラスは削除されました。 - * `sfController::sendEmail()`: 代わりに symfony 1.3 の新しいメーラーを使います。 + * `sfController::sendEmail()`: 代わりに symfony 1.3 で導入された新しいメーラーを使います。 - * `sfGeneratorManager::initialize()`: 何も行いません。 + * `sfGeneratorManager::initialize()`: 何もおこないません。 * `debug_message()`: 代わりに `log_message()` ヘルパーを使います。 - * `sfWebRequest::getMethodName()`: 代わりに `getMethod()` を使います。 + * `sfWebRequest::getMethodName()`: 代わりに `getMethod()` メソッドを使います。 - * `sfDomCssSelector::getTexts()`: `matchAll()->getValues()` を使います。 + * `sfDomCssSelector::getTexts()`: `matchAll()->getValues()` のメソッドチェーンを使います。 - * `sfDomCssSelector::getElements()`: `matchAll()` を使います。 + * `sfDomCssSelector::getElements()`: `matchAll()` メソッドを使います。 - * `sfVarLogger::getXDebugStack()`: 代わりに `sfVarLogger::getDebugBacktrace()` を使います。 + * `sfVarLogger::getXDebugStack()`: 代わりに `sfVarLogger::getDebugBacktrace()` メソッドを使います。 - * `sfVarLogger`: ロギングでは `debug_backtrace` が推奨され、`debug_stack` は廃止予定になりました。 + * `sfVarLogger`: ロギングにおいて `debug_backtrace` オプションが推奨されるようになり、`debug_stack` オプションは廃止予定になりました。 - * `sfContext::retrieveObjects()`: このメソッドを使っていたのは `ObjectHelper` だけなので、廃止予定になりました + * `sfContext::retrieveObjects()`: このメソッドを使っていたのは `ObjectHelper` クラスだけにかぎられていたので、廃止予定になりました。 -次のメソッドと関数は symfony 1.3 で削除されました: +次のメソッドと関数は symfony 1.3 で削除されました。 - * `sfApplicationConfiguration::checkSymfonyVersion()`: 説明は下記の節を参照してください (`check_symfony_version` 設定)。 + * `sfApplicationConfiguration::checkSymfonyVersion()`: くわしい説明は下記の節をご参照ください (`check_symfony_version` 設定)。 クラス ------ -次のクラスは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました: +次のクラスは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。 - * `sfDoctrineLogger`: 代わりに `sfDoctrineConnectionProfiler` を使います。 + * `sfDoctrineLogger`: 代わりに `sfDoctrineConnectionProfiler` クラスを使います。 * `sfNoRouting` と `sfPathInfoRouting` - * `sfRichTextEditor`、`sfRichTextEditorFCK` と `sfRichTextEditorTinyMCE`: これらのクラスはウィジェットシステムに置き換えます (下記の「ヘルパー」の節を参照)。 + * `sfRichTextEditor`、`sfRichTextEditorFCK` と `sfRichTextEditorTinyMCE`: これらのクラスはウィジェットシステムに置き換えます (下記の「ヘルパー」の節をご参照ください)。 * `sfCrudGenerator`、`sfAdminGenerator`、`sfPropelCrudGenerator`、 `sfPropelAdminGenerator`: これらのクラスは symfony 1.0 のアドミンジェネレータで使われていました。 * `sfPropelUniqueValidator`、`sfDoctrineUniqueValidator`: これらのクラスは symfony 1.0 のフォームシステムで使われていました。 - * `sfLoader`: 「メソッドと関数」の節を参照してください。 + * `sfLoader`: 「メソッドと関数」の節をご参照ください。 * `sfConsoleRequest`、`sfConsoleResponse`、`sfConsoleController` - * `sfDoctrineDataRetriever`、`sfPropelDataRetriever`: これらのクラスを使っていたのは `ObjectHelper` だけなので、廃止予定になりました。 + * `sfDoctrineDataRetriever`、`sfPropelDataRetriever`: これらのクラスを使っていたのは `ObjectHelper` クラスだけにかぎられていたので、廃止予定になりました。 * `sfWidgetFormI18nSelectLanguage`、 `sfWidgetFormI18nSelectCurrency` と `sfWidgetFormI18nSelectCountry`: @@ -100,62 +100,62 @@ * `SfExtensionObjectBuilder`、`SfExtensionPeerBuilder`、 `SfMultiExtendObjectBuilder`、`SfNestedSetBuilder`、 `SfNestedSetPeerBuilder`、`SfObjectBuilder`、`SfPeerBuilder`: - Propel のカスタムビルダークラスは Propel 1.4 の新しいビヘイビアシステムに移植されました。 + Propel 専用のビルダークラスは Propel 1.4 で導入された新しいビヘイビアシステムに移植されました。 -次のクラスは symfony 1.3 で削除されました: +次のクラスは symfony 1.3 で削除されました。 - * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は「プロジェクトを 1.2 から 1.3/1.4 にアップグレードする」の「共通フィルタの削除」を参照してください。 + * `sfCommonFilter`: 結果とコードをマイグレートする方法に関する情報は「プロジェクトを1.2から1.3/1.4にアップグレードする」の「共通フィルタの削除」をご参照ください。 ヘルパー -------- -次のヘルパーグループは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました: +次のヘルパーグループは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。 * `sfCompat10Plugin` から提供される symfony 1.0 のフォームシステムに関連するすべてのヘルパー: `DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation` -`form_tag()` ヘルパーの所属グループが `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 このヘルパーは symfony 1.4 でも利用可能です。 +`form_tag()` ヘルパーの所属グループが `Form` ヘルパーグループから `Url` ヘルパーグループに変わりました。 このヘルパーは symfony 1.4 でも利用できます。 -PHP のインクルードパスからヘルパーをロードする機能は symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。ヘルパーの設置場所は、プロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つにしなければなりません。 +PHP のインクルードパスからヘルパーをロードする機能は symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。ヘルパーの設置場所は、プロジェクト、アプリケーションもしくはモジュールの `lib/helper/` ディレクトリのどれか1つに絞らなければなりません。 設定 ---- -`settings.yml` 設定で管理されている次の設定は symfony 1.3 から削除されました: +`settings.yml` ファイルで管理されていた次の設定は symfony 1.3 で削除されました。 - * `check_symfony_version`: この設定は symfony のバージョンが変更される場合にキャッシュの自動消去を可能にするために数年前に導入されました。この設定は主にすべての顧客のあいだで symfony の同じバージョンが共有される共用ホスティングのコンフィギュレーションに役立っていました。symfony 1.1 以降ではバッドプラクティスなので、設定は無効です (プロジェクトごとに symfony のバージョンを組み込む必要があります)。さらに、この設定が `on` にセットされている場合、ファイルの内容を取得する必要があるときに、小さなオーバーヘッドがそれぞれのリクエストに追加されてしまいます。 + * `check_symfony_version`: この設定は symfony のバージョンが変更される場合にキャッシュの自動消去を可能にするために数年前に導入されました。すべての顧客のあいだで symfony の同じバージョンが共有される共用ホスティングのコンフィギュレーションにおいてこの設定は役立っていました。symfony 1.1 以降ではバッドプラクティスになり、設定は無効になっています (プロジェクトごとに symfony のバージョンを組み込む必要があります)。さらに、この設定に `on` がセットされている場合、ファイルの内容を取得する必要があるときに、リクエストごとに小さなオーバーヘッドが発生します。 - * `max_forwards`: この設定は symfony が例外を投げる前に許容される転送の最大回数をコントロールします。この設定を変更しても効果はありません。5回よりも多くの転送が必要な場合、問題の認識とパフォーマンスの両方で問題があります。 + * `max_forwards`: この設定は symfony が例外を投げる前に許容される転送の最大回数をコントロールしていました。この設定を変更しても反映されなくなりました。5回よりも多くの転送が必要になるのであれば、問題の認識とパフォーマンスの両方で問題があります。 - * `sf_lazy_cache_key`: symfony 1.2.6 で大きなパフォーマンス改善のために導入され、この設定はビューキャッシュのために遅延キャッシュキー生成を有効にすることを許可しました。コア開発者は遅延がベストなアイデアと考える一方で、なかにはアクション自身がキャッシュ可能ではないときでも `sfViewCacheManager::isCacheable()` の呼び出しに頼るひともいました。symfony 1.3 に関して、ふるまいは `sf_lazy_cache_key` が `true` にセットされている場合と同じになります。 + * `sf_lazy_cache_key`: この設定は symfony 1.2.6 で大きなパフォーマンス改善のために導入され、ビューキャッシュのために遅延キャッシュキー生成を有効にすることができました。コア開発者は遅延がベストなアイディアと考える一方で、アクション自身がキャッシュ可能ではないときでも `sfViewCacheManager::isCacheable()` メソッド呼び出しに頼るひともいました。symfony 1.3 に関して、ふるまいは `sf_lazy_cache_key` 設定に `true` がセットされている場合と同じになります。 - * `strip_comments`: `strip_comments` は PHP 5.0.x のトークナイザによるバグをかかえるコメント除外機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかった場合に、メモリの大量消費を避けるためにも使われていました。PHP の最小バージョンが 5.2 になったことで、最初の問題は無関係になり、コメント除外機能をシミュレートする正規表現が削除されたことで、2番目の問題はすでに修正されています。 + * `strip_comments`: この設定は PHP 5.0.x のトークナイザによるバグをかかえているコメント除外機能を無効にできるように導入されました。Tokenizer エクステンションが PHP によってコンパイルされていなかった場合に、メモリの大量消費を避けるためにも使われていました。PHP の最小バージョンが5.2になったことで、最初の問題は無関係になり、コメント除外機能をシミュレートする正規表現が削除されたことで、2番目の問題はすでに解決されています。 - * `lazy_routes_deserialize`: このオプションはもはや必要ありません。 + * `lazy_routes_deserialize`: このオプションは不要になりました。 -次の設定は symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました: +次の設定は symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。 - * `calendar_web_dir`、`rich_text_js_dir`: これらの設定を使っていたのは Form ヘルパーグループだけなので symfony 1.3 で廃止予定です。 + * `calendar_web_dir`、`rich_text_js_dir`: これらの設定を使っていたのは Form ヘルパーグループだけにかぎられていたので、symfony 1.3 で廃止予定になりました。 * `validation_error_prefix`、`validation_error_suffix`、 - `validation_error_class`、`validation_error_id_prefix`: これらの設定を使っていたのは Validation ヘルパーグループだけなので、symfony 1.3 で廃止予定です。 + `validation_error_class`、`validation_error_id_prefix`: これらの設定を使っていたのは Validation ヘルパーグループだけにかぎられていたので、symfony 1.3 で廃止予定になりました。 - * `is_internal` (`module.yml`): `is_internal` フラグはアクションがブラウザから呼び出されるのを防ぐために使われました。このフラグは symfony 1.0 でメール送信を保護するために導入されました。このトリックがメールのサポートに必要なくなったので、このフラグは削除され、symfony コアではチェックされなくなりました。 + * `is_internal` (`module.yml`): このフラグは symfony 1.0 で導入され、ブラウザからメール送信アクションが呼び出されないようにするために使われていました。このしくみはメールのサポートに必要なくなりましたので、このフラグは削除され、symfony コアではチェックされなくなりました。 タスク ------ -次のタスクが symfony 1.3 で削除されます: +次のタスクは symfony 1.3 で削除されました。 - * `project:freeze` と `project:unfreeze`: プロジェクトによって使われる symfony のバージョンをプロジェクト自身の内部に組み込むためにこれらのタスクが使われていましたが、もはや必要ありません。長期間にわたって symfony をプロジェクトに組み込むやり方がベストプラクティスになったからです。さらに、symfony のあるバージョンを別のバージョンに切り替える作業は本当にシンプルで、必要なのは `ProjectConfiguration` クラスへのパスを変更することだけです。symfony を手作業で組み込むやり方もシンプルで、必要なのは symfony のディレクトリ全体をプロジェクトの任意の場所にコピーすることだけです (`lib/vendor/symfony/` が推奨されます)。 + * `project:freeze` と `project:unfreeze`: symfony の特定のバージョンをプロジェクト内部に組み込むためにこれらのタスクが使われていましたが、長期間にわたって symfony をプロジェクトに組み込むやりかたがベストプラクティスになりましたので、これらのタスクは不要になりました。さらに、symfony のあるバージョンを別のバージョンに切り替える作業は本当にシンプルで、必要なのは `ProjectConfiguration` クラスのなかでパスを変更することだけです。symfony を組み込む作業もシンプルで、必要なのは symfony のディレクトリ全体をプロジェクトの任意の場所にコピーすることだけです (`lib/vendor/symfony/` ディレクトリがおすすめです)。 -次のタスクは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました: +次のタスクは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。 * symfony 1.0 のすべてのタスクのエイリアス - * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレータモジュールを生成しました。 + * `propel:init-admin`: このタスクは symfony 1.0 のアドミンジェネレータモジュールを生成するのに使われていました。 -次の Doctrine タスクは `doctrine:build` にマージされ、symfony 1.4 で削除されました: +Doctrine の次の一連のタスク群の機能は `doctrine:build` タスクに統合され、symfony 1.4 で削除されました。 * `doctrine:build-all` * `doctrine:build-all-load` @@ -167,23 +167,23 @@ PHP のインクルードパスからヘルパーをロードする機能は sym その他 ------ -次のふるまいは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されます: +次のふるまいは symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。 * `sfParameterHolder::get()`、`sfParameterHolder::has()`、 `sfParameterHolder::remove()`、 `sfNamespacedParameterHolder::get()`、 `sfNamespacedParameterHolder::has()` と `sfNamespacedParameterHolder::remove()` メソッドの配列表記 (`[]`) のサポートは廃止予定になり、symfony 1.4 では利用できません (パフォーマンス向上のため)。 -symfony CLI はグローバルな `--dry-run` オプションを受け取らなくなりました。このオプションは symfony の組み込みタスクによって使われていなかったからです。タスクの1つがこのオプションに依存する場合、このオプションをタスククラスのローカルオプションとして追加できます。 +symfony CLI はグローバルな `--dry-run` オプションを受けつけなくなりました。組み込みのタスクがこのオプションを使っていなかったからです。このオプションに依存しているタスクがあれば、このオプションをタスククラスのローカルオプションに追加することで、変更に対応できます。 symfony 1.0 のアドミンジェネレータの Propel テンプレートと CRUD は symfony 1.4 で削除されました (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。 -「Dynarch Calendar」 (`data/web/calendar/` で見つかります) は symfony 1.4 で削除されました。このライブラリを使っていたのは symfony 1.4 で削除された Form ヘルパーグループだけだからです。 +「Dynarch Calendar」は symfony 1.4 で削除されました (`data/web/calendar/` ディレクトリに配置されていました)。このライブラリを使っていたヘルパーグループが symfony 1.4 で削除された Form ヘルパーグループだけにかぎられていたからです。 -symfony 1.3 に関して、サイトが利用不可能なときに表示されるページは `%SF_APP_CONFIG_DIR%/` と `%SF_CONFIG_DIR%/` ディレクトリでのみ探索されます。まだこのページが `%SF_WEB_DIR%/errors/` に保存されているのであれば、symfony 1.4 へのマイグレーションを行う前に削除しなければなりません。 +symfony 1.3 に関して、サイトが利用不可能なときに表示されるページが探索される場所は `%SF_APP_CONFIG_DIR%/` と `%SF_CONFIG_DIR%/` ディレクトリに限定されるようになりました。まだこのページが `%SF_WEB_DIR%/errors/` ディレクトリに保存されているのであれば、symfony 1.4 へのマイグレーションをおこなう前に削除しなければなりません。 -プロジェクトのルートで `doc/` ディレクトリは生成されなくなりました。このディレクトリが symfony 自身でも使われていないからです。そして関連する `sf_doc_dir` も削除されました。 +プロジェクトのルートで `doc/` ディレクトリは生成されなくなりました。このディレクトリが symfony コアでも使われていなかったからです。変更にともない、`sf_doc_dir` 設定は削除されました。 -以前、`sfDoctrinePlugin_doctrine_lib_path` 設定は Doctrine のカスタム lib ディレクトリを指定するのに使われていましたが、symfony 1.3 で廃止予定になり symfony 1.4 で削除されました。代わりに `sf_doctrine_dir` 設定を使ってください。 +以前、`sfDoctrinePlugin_doctrine_lib_path` 設定は Doctrine の lib ディレクトリを独自に指定するのに使われていましたが、symfony 1.3 で廃止予定になり、symfony 1.4 で削除されました。代わりに `sf_doctrine_dir` 設定を使います。 -symfony のすべての `Base*` クラスは抽象クラスではありません。 +symfony のすべての `Base*` クラスは抽象クラスではなくなりました。 diff --git a/tutorial/ja/upgrade.markdown b/tutorial/ja/upgrade.markdown index 9383d5e..bc20669 100644 --- a/tutorial/ja/upgrade.markdown +++ b/tutorial/ja/upgrade.markdown @@ -1,49 +1,49 @@ -プロジェクトを 1.2 から 1.3/1.4 にアップグレードする -======================================================= +プロジェクトを1.2から1.3/1.4にアップグレードする +================================================ -このドキュメントでは、symfony 1.3/1.4 で行われた変更と symfony 1.2 のプロジェクトをアップグレードするために必要な作業を説明します。 +このドキュメントでは、symfony 1.3/1.4 での変更内容と symfony 1.2 のプロジェクトをアップグレードするために必要な作業を説明します。 -symfony 1.3 で変更または追加された機能の詳細を知りたければ、[「symfony 1.3/1.4 の新しい機能」](http://www.symfony-project.org/tutorial/1_4/ja/whats-new)のチュートリアルをご覧ください。 +symfony1.3 で変更または追加された機能の詳細については、[「symfony 1.3/1.4 の新しい機能」](http://www.symfony-project.org/tutorial/1_4/ja/whats-new)のチュートリアルをご参照ください。 >**CAUTION** ->symfony 1.3/1.4 と互換性のある PHP のバージョンは 5.2.4 およびそれ以降です。PHP 5.2.0 から 5.2.3 までのバージョンでも動くかもしれませんが、保証はありません。 +>symfony 1.3/1.4 と互換性のある PHP のバージョンは5.2.4およびそれ以降です。PHP 5.2.0 から5.2.3までのバージョンでも動くかもしれませんが、保証はございません。 symfony 1.4 にアップグレードする -------------------------------- -すべての廃止予定の機能が削除されたこと以外、symfony 1.4 と symfony 1.3 は同じなので、このバージョンにアップグレードするタスクはありません。symfony 1.4 にアップグレードするには、最初に symfony 1.3 にアップグレードしてから symfony 1.4 リリースに切り替えなければなりません。 +廃止予定の機能がすべて削除されたこと以外、symfony 1.3 と symfony 1.4 は同じなので、このバージョンにアップグレードするタスクはありません。symfony 1.4 にアップグレードするには、最初に symfony 1.3 にアップグレードしてから symfony 1.4 に切り替えなければなりません。 -symfony 1.4 にアップグレードする前に、`project:validate` タスクを実行することで、廃止予定のクラス/メソッド/関数/設定などがプロジェクトで使われていないことを検証することもできます: +symfony 1.4 にアップグレードする前に、`project:validate` タスクを実行して、廃止予定のクラス/メソッド/関数/設定がプロジェクトで使われていないことを検証することもできます。 $ php symfony project:validate このタスクは symfony 1.4 に切り替える前に修正する必要のあるすべてのファイルの一覧を表示します。 -このタスクに使われている正規表現はおおまかなものであり、多くの誤判断をしてしまう可能性があることにご注意ください。また、このタスクは起きる可能性のある問題を特定する助けになるものであり、該当するすべてのファイルを検出できる魔法の道具ではありません。「1.3 での廃止予定および削除される機能」のチュートリアルもじっくり読む必要があります。 +このタスクに使われている正規表現はおおまかなものであり、たくさんの誤判定が起きる可能性があることをあらかじめご了承願います。また、このタスクは起きる可能性のある問題を特定するために用意されたものであり、該当するファイルをすべて検出できる魔法の道具ではありません。「1.3での廃止予定および削除される機能」のチュートリアルもじっくりお読みください。 >**NOTE** ->`sfCompat10Plugin` と `sfProtoculousPlugin` は symfony 1.4 から削除されました。`config/ProjectConfiguration.class.php` などのプロジェクトの設定ファイルのなかでこれらのプラグインを無効にしている場合、プラグインの記述をすべて削除しなければなりません。 +>`sfCompat10Plugin` と `sfProtoculousPlugin` クラスは symfony 1.4 から削除されました。プロジェクトの `config/ProjectConfiguration.class.php` ファイルのなかでこれらのプラグインを無効にしている場合、プラグインの記述をすべて削除しなければなりません。 symfony 1.3 にアップグレードするには？ ------------------------------------- -プロジェクトをアップグレードするには次の手順を踏みます: +プロジェクトをアップグレードするには次の手順を踏みます。 * プロジェクトで使われているすべてのプラグインが symfony 1.3 と互換性があることを確認します。 - * SCM ツールを使っていなければ、かならずプロジェクトのバックアップをとります。 + * SCM ツールを利用していないのであれば、かならずプロジェクトのバックアップをとります。 - * symfony を 1.3 にアップグレードします。 + * symfony を1.3にアップグレードします。 - * プラグインを 1.3 対応のバージョンにアップグレードします。 + * プラグインを1.3対応のバージョンにアップグレードします。 - * 自動アップグレードを実行するために、プロジェクトディレクトリから `project:upgrade1.3` タスクを実行します: + * 自動アップグレードを実行するには、プロジェクトディレクトリから `project:upgrade1.3` タスクを実行します。 $ php symfony project:upgrade1.3 このタスクを複数回実行しても副作用はありません。新しい symfony 1.3 beta/RC もしくは最新のバージョンにアップグレードするたびに、このタスクを実行しなければなりません。 - * 下記で説明されている変更のために、モデルとフォームを再構築する必要があります: + * 下記の節で説明されている変更に対応するために、モデルとフォームを再構築する必要があります。 # Doctrine $ php symfony doctrine:build --all-classes @@ -51,21 +51,21 @@ symfony 1.3 にアップグレードするには？ # Propel $ php symfony propel:build --all-classes - * キャッシュをクリアします: + * キャッシュをクリアします。 $ php symfony cache:clear -残りの節では、symfony 1.3 においてなんらかのアップグレード作業 (自動もしくは手動) が必要な変更を説明します。 +残りの節では、symfony 1.3 においてなんらかのアップグレード作業 (自動もしくは手動) が必要になる変更内容を説明します。 廃止予定の機能 -------------- -symfony 1.3 を開発しているあいだに、たくさんの設定、クラス、メソッド、関数とタスクが廃止予定になるもしくは削除されました。詳しい情報に関して、[「1.3 での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)を参照してくださるようお願いします。 +symfony 1.3 の開発期間の途中で、たくさんの設定、クラス、メソッド、関数とタスクが廃止予定になったもしくは削除されました。くわしい説明は[「1.3での廃止予定および削除される機能」](http://www.symfony-project.org/tutorial/1_4/ja/deprecated)をご参照ください。 オートローディング ------------------- -symfony 1.3 に関して、`lib/vendor/` ディレクトリの下にあるファイルはオートロードの対象にはなりません。`lib/vendor/` サブディレクトリをオートロードの対象に追加するには、アプリケーションの `autoload.yml` 設定ファイルに新しいエントリを追加します: +symfony 1.3 では、`lib/vendor/` ディレクトリの下に配置されているファイルはオートロードの対象に入っていません。`lib/vendor/` サブディレクトリをオートロードの対象に加えるには、新しいエントリをアプリケーションの `autoload.yml` ファイルに登録します。 [yml] autoload: @@ -73,23 +73,25 @@ symfony 1.3 に関して、`lib/vendor/` ディレクトリの下にあるファ path: %SF_LIB_DIR%/vendor/some_lib_dir recursive: on -`lib/vendor/` ディレクトリのオートロードには複数の理由から問題がありました: +`lib/vendor/` ディレクトリのオートロードには複数の理由から問題がありました。 - * すでにオートロードメカニズムがはたらく `lib/vendor/` ディレクトリの下でライブラリを設置する場合、symfony はファイルを再びパースして、たくさんの不要な情報をキャッシュに追加します (#5893 - http://trac.symfony-project.org/ticket/5893 を参照)。 + * すでにオートロードのメカニズムがはたらいている `lib/vendor/` ディレクトリにライブラリを配置する場合、symfony はファイルを再びパースして、たくさんの不要な情報をキャッシュにつけ加えてしまいます (#5893 - http://trac.symfony-project.org/ticket/5893 をご参照ください)。 - * symfony のディレクトリが `lib/vendor/symfony/` という名前でなければ、何らかの問題が起こります。これはプロジェクトのオートローダが symfony ディレクトリ全体を再びパースすることが原因です (#6064 - http://trac.symfony-project.org/ticket/6064 を参照)。 + * symfony のパスが `lib/vendor/symfony/` でなければ、何らかの問題が起きます。これはプロジェクトのオートローダが symfony ディレクトリ全体を再びパースすることが原因です (#6064 - http://trac.symfony-project.org/ticket/6064 をご参照ください)。 symfony 1.3 のオートローダは大文字と小文字を区別しません。 ルーティング ------------ +次のメソッドは以前のバージョンのようにルートを配列として返さなくなりました。 + `sfPatternRouting::setRoutes()`、`sfPatternRouting::prependRoutes()`、 -`sfPatternRouting::insertRouteBefore()` と `sfPatternRouting::connect()` メソッドは以前のバージョンのようにルートを配列として返さなくなりました。 +`sfPatternRouting::insertRouteBefore()` と `sfPatternRouting::connect()` -`lazy_routes_deserialize` オプションはもはや必要ないので削除されました。 +不要になった `lazy_routes_deserialize` オプションは削除されました。 -symfony 1.3 に関して、ルーティングキャッシュが無効になりました。たいていのプロジェクトでは、これはパフォーマンスの観点から最善の選択肢です。ですので、ルーティングキャッシュをカスタマイズしていなければ、このオプションはすべてのアプリケーションで自動的に無効になります。symfony 1.3 にアップグレードした後でプロジェクトの動きが遅くなる場合、役に立っていることを確認するには、ルーティングキャッシュを追加するとよいでしょう。symfony 1.2 のデフォルトコンフィギュレーションに戻すためには、`factories.yml` に次の内容を追加します: +ルーティングキャッシュが無効になりました。たいていのプロジェクトでは、これはパフォーマンスの観点から最善の選択です。ですので、ルーティングキャッシュをカスタマイズしていなければ、すべてのアプリケーションでこのオプションは自動的に無効になります。symfony 1.3 にアップグレードした後でアプリケーションの動きが遅くなる場合、役に立っていることを確認するには、ルーティングキャッシュを追加するとよいでしょう。symfony 1.2 のデフォルトコンフィギュレーションに戻すには、次の内容を `factories.yml` ファイルに書き加えます。 [yml] routing: @@ -107,39 +109,39 @@ JavaScript とスタイルシート ### 共通フィルタの削除 -`sfCommonFilter` は削除され、デフォルトでは使われていません。このフィルタは JavaScript とスタイルシートのタグをレスポンスのコンテンツに自動投入していました。今後これらのアセットを手作業でレスポンスに含めるには、レイアウトのなかで `include_stylesheets()` と `include_javascripts()` ヘルパーを明確に呼び出すことが必要です: +デフォルトで使われなくなった `sfCommonFilter` クラスは symfony 1.4 で削除されました。共通フィルタは JavaScript とスタイルシートのタグをレスポンスのコンテンツに自動投入していました。今後、これらのアセットをレスポンスに含めるには、レイアウトのなかで `include_stylesheets()` と `include_javascripts()` ヘルパーを明確に呼び出すことが必要になります。 [php] -共通フィルタは複数の理由から削除されました: +共通フィルタは複数の理由から削除されました。 - * すでにもっとシンプルですぐれた柔軟な解決方法があります (`include_stylesheets()` と `include_javascripts()` ヘルパー)。 + * すでにもっとシンプルで柔軟な解決策があります (`include_stylesheets()` と `include_javascripts()` ヘルパー)。 - * 最初にフィルタの存在を知らなければならず、「背後」でマジックがはたらいているので、フィルタを無効にするタスクは簡単ではないからです。 + * フィルタの存在をあらかじめ知っていなければ、フィルタが問題の原因になっていることに気づきにくいからです。 * ヘルパーを使えば、レイアウトのなかでいつどこでアセットがインクルードされるのか、きめ細かくコントロールできます (たとえば、`head` タグのスタイルシート、`body` タグが終わる直前の JavaScript) - * つねに暗黙よりも明示的であるほうがすぐれています (おまじないがないのでなんじゃこりゃあと驚かずに済みます。この問題に対する苦情はメーリングリストを参照)。 + * 暗黙の了解を明文化することはつねによいことです (おまじないがないのでなんじゃこりゃぁあと叫ぶ事態に陥らずにすみます。この問題に関する苦情はメーリングリストをご参照ください)。 - * 小さな速度の改善がもたらされます。 + * 処理速度が少し改善されます。 アップグレードするには？ - * すべての `filters.yml` 設定ファイルから `common` フィルタを削除する必要があります (この作業は `project:upgrade1.3` タスクによって自動的に行われます)。 + * すべての `filters.yml` ファイルから `common` フィルタを削除する必要があります (この作業は `project:upgrade1.3` タスクによって自動的におこなわれます)。 - * 以前と同じふるまいを保つには、`include_stylesheets()` と `include_javascripts()` 呼び出しをレイアウトに追加する必要があります (アプリケーションの `templates/` ディレクトリに収められている HTML レイアウトを修正する作業は `project:upgrade1.3` タスクによって自動的に行われます。これらのレイアウトには、`` タグを入れなければなりません。ほかのレイアウト、もしくはレイアウトをもたないが JavaScript ファイルかつ/もしくスタイルシートに依存するページは、手動でアップグレードする必要があります)。 + * 以前と同じふるまいを保つには、`include_stylesheets()` と `include_javascripts()` ヘルパーの呼び出しをレイアウトに追加する必要があります (アプリケーションの `templates/` ディレクトリに収められている HTML レイアウトを修正する作業は `project:upgrade1.3` タスクによって自動的に行われます。これらのレイアウトには、`` タグを入れなければなりません。ほかのレイアウト、もしくはレイアウトをもたないが JavaScript ファイルかつ/もしくスタイルシートに依存するページは、手作業で更新する必要があります)。 >**NOTE** ->`sfCommonFilter` クラスはまだ symfony 1.3 に搭載されているので、必要であれば、`filters.yml` のなかでこのクラスを使うことができます。 +>`sfCommonFilter` クラスはまだ symfony 1.3 に搭載されているので、必要であれば、`filters.yml` ファイルのなかでこのクラスを使うことができます。 タスク ------ -次のタスククラスは改名されました: +次のタスククラスは改名されました。 symfony 1.2 | symfony 1.3 ------------------------- | -------------------------------------------------------------------------- @@ -151,27 +153,27 @@ JavaScript とスタイルシート ### フォーマッタ -`sfFormatter::format()` の第3引数は削除されました。 +`sfFormatter::format()` メソッドの第3引数は削除されました。 エスケーピング --------------- -`ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` は ANSI ではない文字を正しく処理するように更新されました。この変更の前は ANSI の値が`37`から`177`である文字だけがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) だけがエスケープされます。 +`ESC_JS_NO_ENTITIES` によって参照される `esc_js_no_entities()` ヘルパーは修正され、ANSI ではない文字を正しく処理するようになりました。この変更の前は ANSI の値が`37`から`177`である文字だけがエスケープされませんでした。現在はバックスラッシュ (`\`)、クォート (`'` と `"`) 、そして改行 (`\n` と `\r`) だけがエスケープされます。 Doctrine との統合 ----------------- ### Doctrine の必須バージョン -Doctrine の svn:externals は最新の Doctrine 1.2 を使うように更新されました。Doctrine 1.2 の新しい機能に関しては[公式サイトの手引き](http://www.doctrine-project.org/upgrade/1_2)をご覧ください。 +Doctrine の svn:externals が更新され、最新の Doctrine 1.2 が使われるようになりました。Doctrine 1.2 の新しい機能については[公式サイトの手引き](http://www.doctrine-project.org/upgrade/1_2)をご参照ください。 ### アドミンジェネレータの削除機能 -アドミンジェネレータバッチの削除の動作は変更され、レコードをすべて削除する単独の DQL クエリを発行する代わりに、レコードをフェッチして個別のレコードに `delete()` メソッドを発行するようになりました。目的は個別のレコードを削除する際にイベントを立ち上げるためです。 +アドミンジェネレータバッチの削除機能が変更され、レコードをすべて削除する単独の DQL クエリを発行する代わりに、レコードをフェッチして個別のレコードに `delete()` メソッドを発行するようになりました。個別のレコードを削除する際にイベントを起動できるようにするためです。 -### Doctrine プラグインスキーマをオーバーライドする +### Doctrine プラグインのスキーマをオーバーライドする -ローカルスキーマで同じモデルを定義することで、プラグインの YAML スキーマに格納されているモデルをオーバーライドできます。たとえば `sfDoctrineGuardPlugin` の `sfGuardUser` モデルに `email` カラムを追加するには、`config/doctrine/schema.yml` に次のコードを追加します: +ローカルスキーマのなかで同じモデルを定義することで、プラグインの YAML スキーマに記述されたモデルをオーバーライドできます。たとえば `sfDoctrineGuardPlugin` の `sfGuardUser` モデルに `email` カラムを追加するには、`config/doctrine/schema.yml` ファイルに次のコードを書き加えます。 sfGuardUser: columns: @@ -179,11 +181,11 @@ Doctrine の svn:externals は最新の Doctrine 1.2 を使うように更新さ type: string(255) >**NOTE** ->package オプションは Doctrine の機能で symfony プラグインのスキーマに使われます。このことは、モデルのパッケージを作るために package 機能を単独で使うことができることを意味しません。この機能を使えるのは直接および symfony プラグインのなかだけです。 +>package オプションは Doctrine の機能で symfony プラグインのスキーマに使われます。このことは、モデルのパッケージを作るために package 機能を単独で使えることを意味しません。この機能を使える場所は直接か symfony プラグインのなかにかぎられています。 ### クエリのロギング -Doctrine 統合ログクエリは、ロガーオブジェクトに直接アクセスする代わりに `sfEventDispatcher` を使うことで実行されます。さらに、これらのイベントの監視対象はコネクション、もしくはクエリを実行しているステートメントです。ロギングは新しい `sfDoctrineConnectionProfiler` クラスによって行われ、このクラスは `sfDoctrineDatabase` オブジェクトを通してアクセスできます。 +Doctrine 統合ログクエリを実行するには、ロガーオブジェクトに直接アクセスする代わりに `sfEventDispatcher` オブジェクトを使います。さらに、これらのイベントの監視対象はコネクション、もしくはクエリを実行するステートメントです。ロギングは新たに導入された `sfDoctrineConnectionProfiler` クラスが担い、`sfDoctrineDatabase` オブジェクトを通じてこのクラスにアクセスできます。 プラグイン ---------- @@ -193,21 +195,21 @@ Doctrine 統合ログクエリは、ロガーオブジェクトに直接アク ウィジェット ------------ -`sfWidgetFormInput` は抽象クラスです。テキスト入力フィールドは `sfWidgetFormInputText` クラスによって作られます。この変更はフォームクラスのイントロスペクトを簡単にするために行われました。 +`sfWidgetFormInput` は抽象クラスに変更されました。また、テキスト入力フィールドは `sfWidgetFormInputText` クラスによって生成されるようになりました。これらの変更によってフォームクラスのイントロスペクションを実行しやすくなりました。 メーラー -------- -symfony 1.3 では、新しいメーラーファクトリが用意されています。アプリケーションが作られるとき、`factories.yml` には `test` と `dev` 環境の実用的なデフォルトが用意されています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために `factories.yml` のコンフィギュレーションを次のように更新するとよいでしょう: +新しいメーラーファクトリが導入されました。新しいアプリケーションの `factories.yml` ファイルには、`test` と `dev` 環境の実用的なデフォルトが用意されています。既存のプロジェクトをアップグレードする場合、これらの環境に対応させるために、`factories.yml` ファイルのコンフィギュレーションを次のように更新するとよいでしょう。 [yml] mailer: param: delivery_strategy: none -以前のコンフィギュレーションでは、メールは送信されません。もちろん、これらのコンフィギュレーションはまだロギングされ、`mailer` テスターは機能テストでまだ動きます。 +以前のコンフィギュレーションでは、メールは送信されません。もちろん、これらのコンフィギュレーションはロギングされ、`mailer` テスターは機能テストで動きます。 -すべてのメールを1つのメールアドレスで受信したいのであれば、`single_address` 配信戦略を使います (たとえば `dev` 環境): +すべてのメールを1つのメールアドレスで受信するには、`single_address` デリバリストラテジを選びます。たとえば `dev` 環境の場合のコンフィギュレーションは次のようになります。 [yml] dev: @@ -217,21 +219,21 @@ symfony 1.3 では、新しいメーラーファクトリが用意されてい delivery_address: foo@example.com >**CAUTION** ->プロジェクトで Swift Mailer の古いバージョンが使われているのであればそれを削除しなければなりません。 +>Swift Mailer の古いバージョンがプロジェクトで使われているのであれば削除しなければなりません。 YAML ---- -sfYAML は 1.2 の仕様とより多くの互換性をもつようになりました。設定ファイルのなかで変更する必要のあるものは次のとおりです: +sfYAML は YAML 1.2 の仕様とより多くの互換性をもつようになりました。設定ファイルのなかで修正する必要のあるものは次のとおりです。 - * ブール値は文字列の `true` もしくは `false` だけで表現されます。次のリストにある代替文字列が使われているのであれば、`true` もしくは `false` に置き換えなければなりません: + * ブール値をあらわす文字列リテラルは `true` と `false` にかぎられています。次の一覧に入っている代替文字列が使われているのであれば、`true` もしくは `false` に置き換えなければなりません。 * `on`, `y`, `yes`, `+` * `off`, `n`, `no`, `-` -`project:upgrade` タスクは古い構文がどこにあるのか教えてくれますが、修正はしてくれませんので (たとえばあいまいなコメントを避けるため)、手作業で修正しなければなりません。 +`project:upgrade` タスクは古い代替文字列がどこにあるのか教えてくれますが、修正はしてくれませんので、手作業で修正しなければなりません (たとえばコメントを誤って処理しないようにするため)。 -すべての YAML ファイルをチェックしたくなければ、`sfYaml::setSpecVersion()` メソッドを使うことで、YAML パーサーに YAML 1.1 の仕様に準拠するよう強制させることができます: +すべての YAML ファイルをチェックしたくなければ、`sfYaml::setSpecVersion()` メソッドを使うことで、YAML パーサーに YAML 1.1 の仕様に準拠するよう強制させることができます。 [php] sfYaml::setSpecVersion('1.1'); @@ -239,9 +241,9 @@ sfYAML は 1.2 の仕様とより多くの互換性をもつようになりま Propel ------ -symfony の以前のバージョンで使われていた Propel のカスタムビルダークラスは新しい Propel 1.4 のビヘイビアクラスに置き換わりました。この強化内容を利用するには、プロジェクトの `propel.ini` ファイルを更新しなければなりません。 +symfony の以前のバージョンで使われていた Propel 専用のビルダークラスは Propel 1.4 の新しいビヘイビアクラスに置き換わりました。この強化内容を利用するには、プロジェクトの `propel.ini` ファイルを更新しなければなりません。 -古いビルダークラスを削除します: +古いビルダークラスを削除します。 ; builder settings propel.builder.peer.class = plugins.sfPropelPlugin.lib.builder.SfPeerBuilder @@ -251,7 +253,7 @@ symfony の以前のバージョンで使われていた Propel のカスタム propel.builder.objectmultiextend.class = plugins.sfPropelPlugin.lib.builder.SfMultiExtendObjectBuilder propel.builder.mapbuilder.class = plugins.sfPropelPlugin.lib.builder.SfMapBuilderBuilder -そして新しいビヘイビアクラスを追加します: +そして新しいビヘイビアクラスを追加します。 ; behaviors propel.behavior.default = symfony,symfony_i18n @@ -261,14 +263,14 @@ symfony の以前のバージョンで使われていた Propel のカスタム propel.behavior.symfony_behaviors.class = plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorSymfonyBehaviors propel.behavior.symfony_timestampable.class = plugins.sfPropelPlugin.lib.behavior.SfPropelBehaviorTimestampable -`project:upgrade` タスクはこの変更を適用しようとしますが、`propel.ini` でローカルな変更が行われた場合には変更を適用できないことがあります。 +`project:upgrade` タスクはこの変更を適用しようとしますが、`propel.ini` ファイルでローカルな変更がおこなわれていた場合には変更を適用できないことがあります。 -symfony 1.2 では、`BaseFormFilterPropel` クラスは `lib/filter/base` に正しく生成されませんでしたが、symfony 1.3 で訂正され、`lib/filter` に生成されます。`project:upgrade` タスクはこのファイルを移動させます。 +symfony 1.2 では、`BaseFormFilterPropel` クラスは `lib/filter/base/` ディレクトリに正しく生成されませんでしたが、symfony 1.3 で訂正され、`lib/filter/` ディレクトリに生成されます。`project:upgrade` タスクはこのファイルを移動させます。 テスト ------ -ユニットテストのブートストラップファイルである `test/bootstrap/unit.php` はプロジェクトのクラスファイルのオートロードをより上手に扱うように強化されました。次のコードをこのスクリプトに追加しなければなりません: +ユニットテストのブートストラップファイルである `test/bootstrap/unit.php` はプロジェクトのクラスファイルのオートロードをより適切に処理するように強化されました。このスクリプトに次のコードを書き加えなければなりません。 [php] $autoload = sfSimpleAutoload::getInstance( @@ -280,4 +282,4 @@ symfony 1.2 では、`BaseFormFilterPropel` クラスは `lib/filter/base` に ))); $autoload->register(); -`project:upgrade` タスクはこの変更を適用しようとしますが、`test/bootstrap/unit.php` でローカルな変更が行われた場合には変更を適用できないことがあります。 +`project:upgrade` タスクはこの変更を適用しようとしますが、`test/bootstrap/unit.php` ファイルのなかでローカルな変更がおこなわれていた場合には変更を適用できないことがあります。 diff --git a/tutorial/ja/whats-new.markdown b/tutorial/ja/whats-new.markdown index 0063868..20bdf1e 100644 --- a/tutorial/ja/whats-new.markdown +++ b/tutorial/ja/whats-new.markdown @@ -1,24 +1,24 @@ symfony 1.3/1.4 の新しい機能 ============================= -このチュートリアルでは symfony 1.3/1.4 に関する技術的な内容をおおまかに紹介します。このチュートリアルの対象者はすでに symfony 1.2 で作業をしており、symfony 1.3/1.4 の新しい機能を早く学びたい開発者です。 +このチュートリアルでは symfony 1.3/1.4 の新しい機能をおおまかに説明します。このチュートリアルの対象読者は symfony 1.2 で作業経験があり、symfony 1.3/1.4 の新しい機能をてっとり早く学びたい方です。 -最初に、symfony 1.3/1.4 と互換性のある PHP のバージョンが 5.2.4 およびそれ以降であることにご注意ください。 +symfony 1.3/1.4 と互換性のある PHP のバージョンは5.2.4およびそれ以降であることにご了承願います。 -symfony 1.2 からアップグレードしたいのであれば、[「プロジェクトを 1.2 から 1.3/1.4 にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご覧ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要なすべての情報が手に入ります。 +symfony 1.2 からアップグレードする手順については、[「プロジェクトを1.2から1.3/1.4にアップグレードする」](http://www.symfony-project.org/tutorial/1_4/ja/upgrade)のページをご参照ください。プロジェクトを symfony 1.3/1.4 に安全にアップグレードするために必要な情報をすべて得られます。 メーラー -------- -symfony 1.3/1.4 では Swift Mailer 4.1 をベースとする標準メーラーが新たに導入されました。 +Swift Mailer 4.0 をもとにした標準メーラーが新たに導入されました。 -メールの送信方法はシンプルで、アクションから `composeAndSend()` メソッドを使うだけです: +アクションクラスのなかで `composeAndSend()` メソッドを呼び出せば、メールをかんたんに送信できます。 [php] $this->getMailer()->composeAndSend('from@example.com', 'to@example.com', 'Subject', 'Body'); -より柔軟性をもたせる必要があれば、`compose()` メソッドを使って後で送信することもできます。添付ファイルをメッセージに追加する方法は次のとおりです: +メールを送信するタイミングは `compose()` メソッドを使って柔軟に調整できます。メッセージにファイルを添付する方法は次のようになります。 [php] $message = $this->getMailer()-> @@ -27,35 +27,35 @@ symfony 1.3/1.4 では Swift Mailer 4.1 をベースとする標準メーラー ; $this->getMailer()->send($message); -メーラーはとても強力なので、詳しい情報は公式マニュアルを参照してください。 +メーラーの機能は充実しているので、くわしい説明は公式マニュアルをご参照ください。 セキュリティ ----------- -`generate:app` タスクで新しいアプリケーションを作るとき、セキュリティの設定はデフォルトで有効です: +`generate:app` タスクで作られた直後のアプリケーションでは、セキュリティの設定はデフォルトで有効になっています。 - * `escaping_strategy`: デフォルト値は `true` です (`--escaping-strategy` オプションで無効にできます)。 - * `escaping_strategy`: デフォルト値は `true` です (`--escaping-strategy` オプションで無効にできます)。 + * `escaping_strategy`: デフォルトは `true` です (`--escaping-strategy` オプションで無効にできます)。 + * `escaping_strategy`: デフォルトは `true` です (`--escaping-strategy` オプションで無効にできます)。 - * `csrf_secret`: デフォルトでランダムなパスワードが生成されます。CSRF 防止機能は標準で有効です (`--csrf-secret` オプションで無効にできます)。`settings.yml` 設定ファイルを編集するか、`--csrf-secret` オプションを指定することで、初期パスワードを変更することをぜひおすすめします。 + * `csrf_secret`: デフォルトでは、ランダムなパスワードが生成され、CSRF 防止機能は有効になっています (`--csrf-secret` オプションで無効にできます)。初期パスワードを変更しておくことをぜひおすすめします。パスワードを変更するには、`settings.yml` ファイルを編集するか、`--csrf-secret` オプションで指定します。 -ウィジット ---------- +ウィジェット +------------ ### 標準ラベル -ラベルがフィールド名から自動生成される場合、サフィックスの `_id` はつかなくなりました: +フィールド名から自動生成されたラベルにサフィックスの `_id` がつかなくなりました。 * `first_name` => First name (以前と同じ) * `author_id` => Author (以前は「Author id」) ### `sfWidgetFormInputText` -`sfWidgetFormInput` クラスは抽象クラスになりました。テキスト入力フィールドは `sfWidgetFormInputText` クラスのなかで作られます。この変更によってフォームクラスのイントロスペクションはより簡単になりました。 +`sfWidgetFormInput` クラスは抽象クラスに変更され、テキスト入力フィールドは `sfWidgetFormInputText` クラスによって生成されるようになりました。この変更によってフォームクラスのイントロスペクションをおこないやすくなりました。 -### 国際化ウィジェット +### 国際対応ウィジェット -次のウィジェットが導入されました: +次の４つのウィジェットが導入されました。 * `sfWidgetFormI18nChoiceLanguage` * `sfWidgetFormI18nChoiceCurrency` @@ -66,7 +66,7 @@ symfony 1.3/1.4 では Swift Mailer 4.1 をベースとする標準メーラー ### 流れるようなインターフェイス -ウィジットは流れるようなインターフェイスを実装するようになりました: +ウィジェットに流れるようなインターフェイスが実装されました。 * `sfWidgetForm`: `setDefault()`、`setLabel()`、`setIdFormat()`、`setHidden()` @@ -82,22 +82,22 @@ symfony 1.3/1.4 では Swift Mailer 4.1 をベースとする標準メーラー `setHelp()`、`setParent()`、`setPositions()` バリデータ ------------- +---------- ### `sfValidatorRegex` -`sfValidatorRegex` に新しい `must_match` オプションが導入されました。このオプションが `false` にセットされている場合、正規表現は渡されるバリデータにマッチしません。 +`sfValidatorRegex` バリデータに `must_match` オプションが新たに導入され、このオプションに `false` をセットすると、正規表現は渡されるバリデータにマッチしなくなります。 -`sfValidatorRegex` の `pattern` オプションの値は呼び出されるときに正規表現を返す `sfCallable` のインスタンスにしなければならなくなりました。 +`sfValidatorRegex` バリデータの `pattern` オプションにセットできる値の必須条件が呼び出されるときに正規表現を返す `sfCallable` のインスタンスに変更されました。 ### `sfValidatorUrl` -`sfValidatorUrl` に新しい `protocols` オプションが導入されました。次のように特定のプロトコルに制限できるようになりました: +`sfValidatorUrl` バリデータに `protocols` オプションが新たに導入されました。次のように特定のプロトコルに制限できるようになりました。 [php] $validator = new sfValidatorUrl(array('protocols' => array('http', 'https'))); -デフォルトでは次のプロトコルが許可されています: +デフォルトでは、次のプロトコルが許可されています。 * `http` * `https` @@ -106,47 +106,47 @@ symfony 1.3/1.4 では Swift Mailer 4.1 をベースとする標準メーラー ### `sfValidatorSchemaCompare` -`sfValidatorSchemaCompare` クラスに2つの新しいコンパレータが導入されました: +`sfValidatorSchemaCompare` クラスに比較演算のための2つの定数が新たに導入されました。 - * `IDENTICAL` は `===` と同等です; - * `NOT_IDENTICAL` は `!==` と同等です; + * `IDENTICAL` は `===` と同等です。 + * `NOT_IDENTICAL` は `!==` と同等です。 ### `sfValidatorChoice`、`sfValidator(Propel|Doctrine)Choice` -`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデータに、`multiple` オプションが `true` の場合のみ有効になる2つのオプションが新たに導入されました: +`sfValidatorChoice`、`sfValidatorPropelChoice` そして `sfValidatorDoctrineChoice` バリデータに2つのオプションが新たに導入されました。 `multiple` オプションに `true` がセットされている場合にかぎり、これらのバリデータのオプションは有効です。 * `min` 必須選択の最小数 * `max` 必須選択の最大数 -### 国際化対応バリデータ +### 国際対応バリデータ -次のバリデータが導入されました: +次のバリデータが導入されました。 * `sfValidatorI18nChoiceTimezone` ### デフォルトのエラーメッセージ -`sfForm::setDefaultMessage()` メソッドを次のように使うことで、デフォルトのエラーメッセージをグローバルに定義できるようになりました: +`sfForm::setDefaultMessage()` メソッドを呼び出すことで、グローバルなエラーメッセージのデフォルトを定義できるようになりました。 [php] sfValidatorBase::setDefaultMessage('required', 'This field is required.'); -上記のコードはすべてのバリデータのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデータが作られる前に定義しておかなければならないことにご注意ください (コンフィギュレーションクラスがよい場所です)。 +上記のコードはすべてのバリデータのデフォルトメッセージである 'Required.' をオーバーライドします。デフォルトメッセージはバリデータが生成される前に定義しておかなければならないことにご注意ください (最適な場所はコンフィギュレーションクラスです)。 >**NOTE** ->`setRequiredMessage()` と `setInvalidMessage()` メソッドは廃止予定なので、代わりに、新しい `setDefaultMessage()` メソッドを呼び出します。 +>`setRequiredMessage()` と `setInvalidMessage()` メソッドが廃止予定になりましたので、新たに導入された `setDefaultMessage()` メソッドを代わりに呼び出します。 -symfony がエラーを表示するとき、使われるエラーメッセージは次のように決められます: +エラーメッセージは次のように決められます。 - * バリデータが作られるときに渡されるメッセージが探索されます (バリデータのコンストラクタの第2引数経由); + * バリデータが初期化される際に渡されたメッセージが探索されます (バリデータのコンストラクタの第2引数経由)。 - * コンストラクタで定義されていなければ、`setDefaultMessage()` メソッドで定義されている初期メッセージが探索されます; + * コンストラクタで指定されていなければ、`setDefaultMessage()` メソッドで指定されたデフォルトメッセージが探索されます。 - * `setDefaultMessage()` メソッドで定義されていなければ (メッセージが `addMessage()` メソッドで追加されている場合)、バリデータ自身で定義される初期メッセージに戻ります。 + * `setDefaultMessage()` メソッドで指定されていなければ (メッセージが `addMessage()` メソッドで追加された場合)、バリデータ自身で定義されているデフォルトメッセージに戻ります。 ### 流れるようなインターフェイス -バリデータは流れるようなインターフェイスを実装するようになりました: +バリデータに流れるようなインターフェイスが実装されるようになりました。 * `sfValidatorSchema`: `setPreValidator()`、`setPostValidator()` @@ -158,14 +158,14 @@ symfony がエラーを表示するとき、使われるエラーメッセージ ### `sfValidatorFile` -`php.ini` で `file_uploads` が無効にされている場合、`sfValidatorFile` のインスタンスを作る際に例外が投げられます。 +`php.ini` ファイルの `file_uploads` ディレクティブが無効になっている場合、`sfValidatorFile` のインスタンスが生成される際に例外が投げられます。 フォーム -------- ### `sfForm::useFields()` -新しい `sfForm::useFields()` メソッドは、引数に渡されるフィールド以外の、隠しフィールドではないすべてのフィールドをフォームから削除します。ときには、不要なフィールドの割り当てを解除するよりも、フォームで保ちたいフィールドを明確に指示するほうが簡単です。たとえば基底フォームに新しいフィールドを追加するとき、これらのフィールドは明確に追加されるまでフォームに自動表示されることはありません (モデルフォームのなかで新しいカラムを関連テーブルに追加する場合を考えてください): +新たに導入された `sfForm::useFields()` メソッドは、引数に渡されたフィールドを除いて、隠しフィールドではないすべてのフィールドをフォームから削除します。不要なフィールドの割り当てを解除するよりも、フォームで保ちたいフィールドを明確に指定するほうがかんたんな場合があります。たとえば、基底フォームに新しいフィールドを追加する場合、これらのフィールドは明確に追加されるまでフォームに表示されることはありません (モデルフォームのなかで関連テーブルに新しいカラムを追加する場合を思い浮かべてください)。 [php] class ArticleForm extends BaseArticleForm @@ -176,124 +176,126 @@ symfony がエラーを表示するとき、使われるエラーメッセージ } } -デフォルトでは、フィールドの配列はフィールドの順序を変更するのにも使われます。自動的な並べ替えを無効にするには、`useFields()` の第2引数に `false` を渡します。 +デフォルトでは、フィールドの配列はフィールドの順序変更にも使われます。自動的な並べ替えを無効にするには、`useFields()` メソッドの第2引数に `false` を渡します。 ### `sfForm::getEmbeddedForm($name)` -`->getEmbeddedForm()` メソッドを使って特定の組み込みフォームにアクセスできるようになりました。 +`->getEmbeddedForm()` メソッドを使って特定の埋め込みフォームにアクセスできるようになりました。 ### `sfForm::renderHiddenFields()` -`->renderHiddenFields()` メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が導入され、これはフォーマッタを使って組み込みフォームをレンダリングする際に便利です: +`->renderHiddenFields()` メソッドは埋め込みフォームからの隠しフィールドをレンダリングするようになりました。また、再帰処理を無効にする引数が導入されました。これはフォーマッタを使って埋め込みフォームをレンダリングする際に役立ちます。 [php] - // 組み込みフォームからのフィールドを含めて、すべての隠しフィールドをレンダリングする + // 埋め込みフォームからのフィールドを含めて、すべての隠しフィールドをレンダリングします echo $form->renderHiddenFields(); - // 再帰処理なしで隠しフィールドをレンダリングする + // 再帰処理なしで隠しフィールドをレンダリングします echo $form->renderHiddenFields(false); ### `sfFormSymfony` -新しい `sfFormSymfony` クラスは symfony フォームにイベントディスパッチャを導入します。`self::$dispatcher` を通してフォームクラス内部のディスパッチャにアクセスできます。次のフォームイベントが symfony によって通知されます: +新たに導入された `sfFormSymfony` クラスは symfony のフォームシステムにイベントディスパッチャをもたらします。`self::$dispatcher` を通じてフォームクラス内部のディスパッチャにアクセスできます。次のフォームイベントが symfony によって通知されます。 - * `form.post_configure`: このイベントはフォームが設定された後で通知されます。 - * `form.filter_values`: このイベントは、マージされ汚染されているパラメータと、バインドされる直前のファイルの配列をフィルタリングします。 + * `form.post_configure`: このイベントはフォームが設定された後で通知されます。 + * `form.filter_values`: このイベントは、マージされ、汚染されているパラメータと、バインドされる直前のファイルの配列にフィルタをかけます。 * `form.validation_error`: フォームバリデーションが通らないときに、このイベントが通知されます。 * `form.method_not_found`: 見つからないメソッドが呼び出されるときに、このイベントが通知されます。 ### `BaseForm` -symfony 1.3/1.4 では、すべての新しいプロジェクトに `BaseForm` クラスが用意されています。このクラスは Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使います。`sfDoctrinePlugin` と `sfPropelPlugin` によって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば、継承するクラスは `sfForm` ではなく `BaseForm` です。 +`BaseForm` クラスがすべての新しいプロジェクトに用意されるようになりました。このクラスの用例は Form コンポーネントを拡張したり、プロジェクト固有の機能を追加することなどです。`sfDoctrinePlugin` と `sfPropelPlugin` クラスによって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば、継承させるクラスは `sfForm` ではなく `BaseForm` です。 ### `sfForm::doBind()` -ロジックをわかりやすくするために、汚染されているパラメータのクリーニングは `->doBind()` メソッドに隔離されました。このメソッドは`->bind()` からパラメータとファイルのマージ済みの配列を受け取ります。 +ロジックをわかりやすくするために、汚染されているパラメータのクリーニングは `->doBind()` メソッドに隔離されました。このメソッドは `->bind()` メソッドからパラメータとファイルのマージずみの配列を受けとります。 ### `sfForm(Doctrine|Propel)::doUpdateObject()` -ロジックをわかりやすくするために、Doctrine と Propel のフォームクラスに `->doUpdateObject()` メソッドが導入されました。このメソッドは すでに `->processValues()` によって処理済みの値の配列を `->updateObject()` から受け取ります。 +ロジックをわかりやすくするために、Doctrine と Propel 対応のフォームクラスに `->doUpdateObject()` メソッドが導入されました。このメソッドはすでに `->processValues()` メソッドによって処理ずみの値の配列を `->updateObject()` メソッドから受けとります。 ### `sfForm::enableLocalCSRFProtection()` と `sfForm::disableLocalCSRFProtection()` -`sfForm::enableLocalCSRFProtection()` と `sfForm::disableLocalCSRFProtection()` メソッドを使うとき、あなたのクラスの `configure()` メソッドから CSRF 防止機能を簡単に設定できます。 +`sfForm::enableLocalCSRFProtection()` と `sfForm::disableLocalCSRFProtection()` メソッドを使えば、自前のフォームクラスの `configure()` メソッドから CSRF 防止機能をかんたんに設定できます。 -CSRF 防止機能を無効にするには、`configure()` メソッドに次のコードを追加します: +CSRF 防止機能を無効にするには、`configure()` メソッド呼び出しのなかで次のコードを書き加えます。 [php] $this->disableLocalCSRFProtection(); -フォームインスタンスを作る際に CSRF 対策の秘密の文字列を渡していたとしても、`disableLocalCSRFProtection()` を呼び出すことで CSRF 防止機能を無効にできます。 +フォームインスタンスを作る際に CSRF 対策の秘密の文字列を渡していたとしても、`disableLocalCSRFProtection()` メソッドを呼び出して CSRF 防止機能を無効にすることができます。 ### 流れるようなインターフェイス -`sfForm` メソッドは流れるようなインターフェイスを実装するようになりました: `addCSRFProtection()`、`setValidators()`、`setValidator()`、 +`sfForm` に流れるようなインターフェイスが実装されました。 + +`addCSRFProtection()`、`setValidators()`、`setValidator()`、 `setValidatorSchema()`、`setWidgets()`、`setWidget()`、 `setWidgetSchema()`、`setOption()`、`setDefault()` そして `setDefaults()` オートローダ --------------- +------------- -symfony のすべてのオートローダは PHP に合わせて大文字と小文字を区別しなくなりました。 +PHP にならい、symfony のすべてのオートローダは大文字と小文字を区別しなくなりました。 ### `sfAutoloadAgain` (実験的な機能) -デバッグモードでの用途を目的とする特殊なオートローダが導入されました。新しい `sfAutoloadAgain` クラスは symfony の標準オートローダをリロードし該当するクラスを求めてファイルシステムを探索します。純粋な効果は、プロジェクトに新しいタスクを追加した後で `symfony cc` を実行する必要がなくなることです。 +デバッグモードでの用途を目的とする特殊なオートローダが導入されました。新たに導入された `sfAutoloadAgain` クラスは symfony の標準オートローダをリロードし、該当するクラスを求めてファイルシステムを探索します。純粋な効果は、プロジェクトに新しいタスクを追加した後で `symfony cc` コマンドを実行しなくてすむことです。 テスト ----- -### テストのスピードアップ +### テストの実行時間の短縮 -大規模なテストスイートで特にテストが通らない場合、変更するたびにすべてのテストを実行するのに時間がとてもかかる可能性があります。なぜならテストを修正するたびに、何も壊れていないことを確認するためにテストスイート全体を再度実行することになるからです。しかしながら、テストを修正しないかぎり、すべてのテストを再実行する必要はありません。symfony 1.3/1.4 では、`test:all` と `symfony:test` タスクのために前回の実行時に通らなかったテストだけを再実行する `--only-failed` オプション (ショートカットは `-f`) が導入されました: +大規模なテストスイートでテストが通らない場合、テストを修正するたびに、何も壊れていないことを確認するためにテストスイート全体を再度実行することになるので時間がかかります。しかしながら、通らなかったテストが修正されていないのであれば、すべてのテストを再実行するのは時間の無駄です。symfony 1.3/1.4 では、`test:all` と `symfony:test` タスクに `--only-failed` オプション (ショートカットは `-f`) が導入され、前回の実行時に通らなかったテストだけを再実行できるようになりました。 $ php symfony test:all --only-failed -どのように動くのかを説明します。まず最初に、すべてのテストはいつもどおりに実行されます。引き続きテストを実行すると、最後のテストで通らなかったものだけが実行されます。コードを修正して一部のテストが通れば、次回以降の実行から除外されます。再びすべてのテストが通れば、完全なテストスイートが実行され、徹底的に繰り返すことができます。 +どのようなしくみなのか説明します。まず最初に、すべてのテストは通常どおりに実行されます。引きつづきテストを実行すると、最後に実行したテストで通らなかったものだけが実行されます。コードを修正して一部のテストが通れば、次回以降の実行から除外されます。すべてのテストが通るようになると、完全なテストスイートが徹底的に実行されます。 ### 機能テスト -リクエストが例外を生成するとき、より簡単にデバッグできるように、レスポンステスターの `debug()` メソッドは、標準出力の HTML 形式の代わりに、人間が理解できる例外の説明をテキスト形式で出力するようになりました。 +リクエストが例外を発生させる場合において、レスポンステスターの `debug()` メソッドが出力する例外の説明のフォーマットが HTML からテキストに変更され、デバッグ作業がしやすくなりました。 -レスポンスの内容全体に対して正規表現で検索できるように、`sfTesterResponse` に新しい `matches()` メソッドが導入されました。このメソッドは `checkElement()` が使えない XML 形式ではないレスポンスに重宝します。力不足の `contains()` メソッドの代わりとして使うこともできます: +`sfTesterResponse` クラスに `matches()` メソッドが新たに導入され、レスポンスの内容全体を正規表現で検索できるようになりました。このメソッドは `checkElement()` メソッドが扱えない XML 形式ではないレスポンスの処理にとても役立ちます。力不足の `contains()` メソッドの代わりに使うこともできます。 [php] $browser->with('response')->begin()-> - matches('/I have \d+ apples/')-> // 正規表現を引数にとる - matches('!/I have \d+ apples/')-> // 冒頭の ! は正規表現がマッチしてはならないことを意味する - matches('!/I have \d+ apples/i')-> // 正規表現の修飾子も追加できる + matches('/I have \d+ apples/')-> // 正規表現を引数にとります + matches('!/I have \d+ apples/')-> // 冒頭の ! は正規表現がマッチしないことを意味します + matches('!/I have \d+ apples/i')-> // 正規表現の修飾子も追加できます end(); ### JUnit と互換性のある XML 出力 -`--xml` オプションをつけることで、テストタスクは JUnit と互換性のある XML ファイルも出力できるようになりました: +`--xml` オプションを指定して JUnit と互換性のある XML ファイルを出力できるようになりました。 $ php symfony test:all --xml=log.xml -### 簡単なデバッグ +### デバッグ作業の軽減 -テストが通らないことをテストハーネスが報告するとき、デバッグを簡単にするために、通らないテストについて詳細な出力を指示する `--trace` オプションを指定できるようになりました: +`--trace` オプションを指定して通らないテストに関するくわしい内容を出力できるようになり、デバッグ作業がやりやすくなりました。 $ php symfony test:all -t ### lime によるカラー出力 -symfony 1.3/1.4 では、lime は正しくカラー出力するようになりました。このことが意味するのは、ほとんどの場合において `lime_test` の lime コンストラクタの第2引数を省略できるということです: +symfony 1.3/1.4 では、lime のカラー出力が正しくおこなわれるようになりました。このことが意味するのは、たいていの場合、`lime_test` のインスタンスを作る際にコンストラクタの第2引数を省略できるということです。 [php] $t = new lime_test(1); ### `sfTesterResponse::checkForm()` -レスポンステスターに `->checkForm()` メソッドが導入され、フォームのすべてのフィールドが正しくレンダリングされてレスポンスに含まれているかどうかを確かめることがより簡単になりました: +レスポンステスターに `->checkForm()` メソッドが導入され、フォームのフィールドがすべて正しくレンダリングされ、レスポンスに含まれているかどうかを確認しやすくなりました。 [php] $browser->with('response')->begin()-> checkForm('ArticleForm')-> end(); -もしくは望むのであれば、フォームオブジェクトを渡すことができます: +お望みであれば、フォームオブジェクトを渡すことができます。 [php] @@ -301,7 +303,7 @@ symfony 1.3/1.4 では、lime は正しくカラー出力するようになり checkForm($browser->getArticleForm())-> end(); -複数のフォームがレスポンスに含まれる場合、どの DOM 部分をテストするのかをきめ細かく指定するために、CSS セレクタを提供するオプションが用意されています: +CSS セレクタを指定するオプションが用意され、複数のフォームがレスポンスに含まれる場合、DOM のどの部分をテストするのかをきめ細かく指定できるようになりました。 [php] $browser->with('response')->begin()-> @@ -310,21 +312,21 @@ symfony 1.3/1.4 では、lime は正しくカラー出力するようになり ### `sfTesterResponse::isValid()` -レスポンスが妥当な XML であるのかチェックするために、レスポンステスターの `->isValid()` メソッドを使うことができます: +レスポンステスターに `->isValid()` メソッドが追加され、レスポンスが妥当な XML であるのかどうかをチェックできるようになりました。 [php] $browser->with('response')->begin()-> isValid()-> end(); -引数に `true` を渡すことで、ドキュメントの種類に対するレスポンスをバリデートすることもできます: +引数に `true` を渡せば、ドキュメントの種類に対するレスポンスをバリデートすることもできます。 [php] $browser->with('response')->begin()-> isValid(true)-> end(); -バリデートする対象として XSD もしくは RelaxNG スキーマがある場合、このスキーマファイルへのパスを渡すことができます: +XSD もしくは RelaxNG スキーマをバリデーションの対象に入れるには、スキーマファイルへのパスを渡します。 [php] $browser->with('response')->begin()-> @@ -333,14 +335,14 @@ symfony 1.3/1.4 では、lime は正しくカラー出力するようになり ### `context.load_factories` をリスニングする -機能テストに `context.load_factories` イベントのリスナーを追加できるようになりました。symfony の以前のバージョンではこのリスナーは利用できませんでした: +機能テストに `context.load_factories` イベントのリスナーを追加できるようになりました。symfony の以前のバージョンではこのリスナーを利用できませんでした。 [php] $browser->addListener('context.load_factories', array($browser, 'listenForNewContext')); ### 改良された `->click()` -`->click()` メソッドに CSS セレクタを渡すことが可能になり、セマンティックにしたい要素をターゲットにすることがとても簡単になりました: +`->click()` メソッドに CSS セレクタを渡せるようになり、セマンティックにしたい要素をターゲットに指定することがとてもかんたんになりました。 [php] $browser @@ -355,62 +357,62 @@ symfony CLI はターミナルウィンドウの幅を検出することを試 ### `sfTask::askAndValidate()` -ユーザーに質問して得られる入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新たに導入されました: +`sfTask::askAndValidate()` メソッドが新たに導入され、ユーザーに質問して得られる入力内容をバリデートできるようになりました。 [php] $answer = $this->askAndValidate('What is you email?', new sfValidatorEmail()); -このメソッドはオプションの配列も受け取ることができます (詳しい情報は API ドキュメントを参照)。 +このメソッドはオプションの配列も受けとることができます (くわしい説明は API のドキュメントをご参照ください)。 ### `symfony:test` -特定のプラットフォームで symfony が正しく動くのかをチェックするために、symfony のテストスイートを実行することが必要な場合があります。従来では、この確認作業を行うために symfony に附属する `prove.php` スクリプトの存在を知らなければなりませんでした。symfony 1.3/1.4 では、組み込みのタスク、コマンドラインから symfony のコアテストスイートを実行できる `symfony:test` タスクが導入され、ほかのタスクと同じように使うことができます: +特定のプラットフォームで symfony が正しく動くのかチェックするために、symfony のテストスイートを実行することが必要な場合があります。従来では、この確認作業をおこなうために、symfony に附属している `prove.php` スクリプトの存在を知らなければなりませんでした。symfony 1.3/1.4 では、ほかのタスクと同じように扱える `symfony:test` タスクが導入され、symfony コアのテストスイートを組み込みのタスク、コマンドラインから実行できます。 $ php symfony symfony:test -`php test/bin/prove.php` に慣れ親しんでいれば、同等の `php data/bin/symfony symfony:test` コマンドを使うことができます。 +`php test/bin/prove.php` に慣れ親しんでいれば、同等の `php data/bin/symfony symfony:test` コマンドを選ぶこともできます。 ### `project:deploy` -`project:deply` タスクは少し改良されました。ファイルの転送状況をリアルタイムで表示するようになりました。ただし、`-t` オプションが指定されているときだけです。オプションが指定されていなければ、タスクは何も表示しません。もちろんエラーの場合は除きます。エラーのときには、問題がわかりやすいように、赤色を背景にエラー情報が出力されます。 +`project:deply` タスクは少し改良され、`-t` オプションが指定されていれば、ファイルの転送状況がリアルタイムで表示されるようになりました。`-t` オプションが指定されていなければ、タスクは何も表示しません。もちろんエラーの場合は除きます。エラーの場合に表示されるエラー情報の背景が赤色になり、問題が把握しやすくなりました。 ### `generate:project` -symfony 1.3/1.4 で `generate:project` タスクを実行するとき、初期設定では ORM は Doctrine になります: +`generate:project` タスクを実行するときに選ばれるデフォルトの ORM は Doctrine になりました。 $ php /path/to/symfony generate:project foo -Propel のプロジェクトを生成するには、`--orm` オプションを指定します: +Propel のプロジェクトを生成するには、`--orm` オプションで指定します。 $ php /path/to/symfony generate:project foo --orm=Propel -Propel もしくは Doctrine のどちらも使いたくなければ、`--orm` オプションに `none` を渡します: +Propel もしくは Doctrine のどちらも使いたくなければ、`--orm` オプションに `none` を指定します。 $ php /path/to/symfony generate:project foo --orm=none -新しい `--installer` オプションのおかげで、新たに生成されるプロジェクトの詳細をカスタマイズできる PHP スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドのなかで使うことができます。次のようにもっと便利なメソッドがあります: +新たに導入された `--installer` オプションに PHP スクリプトを指定することで、新たに生成されるプロジェクトを細かくカスタマイズできるようになりました。PHP スクリプトはタスクのメソッドのなかでも使うことができます。便利なメソッドがとりそろえられています。 -`installDir()`、`runTask()`、`ask()`、`askConfirmation()`、`askAndValidate()`、 -`reloadTasks()`、`enablePlugin()` そして `disablePlugin()` + installDir()、runTask()、ask()、askConfirmation()、askAndValidate()、 + reloadTasks()、enablePlugin() そして disablePlugin() -詳しい情報は公式ブログの[記事](http://www.symfony-project.org/blog/2009/06/10/new-in-symfony-1-3-project-creation-customization)に掲載されています。 +くわしい解説は[公式ブログ](http://www.symfony-project.org/blog/2009/06/10/new-in-symfony-1-3-project-creation-customization)に掲載されています。 -プロジェクトを生成するとき、第2引数に著者の名前を渡すことができます。この引数は、symfony が新しいクラスを生成する際に PHPDoc の `@author` タグに使う値を指定します: +プロジェクトを生成するとき、著者の名前を第2引数に渡すことができます。symfony は新しいクラスを生成する際に PHPDoc の `@author` タグの値にタスクに渡された引数を使います。 $ php /path/to/symfony generate:project foo "Joe Schmo" ### `sfFileSystem::execute()` -`sfFileSystem::sh()` メソッドはより強力な機能をもつ `sfFileSystem::execute()` メソッドに置き換わりました。このメソッドは `stdout` と `stderr` 出力のリアルタイム処理のコールバックを引数にとります。また両方の出力を配列として返すこともできます。使い方の例は `sfProjectDeployTask` クラスで見つかります。 +`sfFileSystem::sh()` メソッドはより強力な `sfFileSystem::execute()` メソッドに置き換わりました。このメソッドは `stdout` と `stderr` 出力のリアルタイム処理のコールバックを引数にとります。そして、両方の出力を配列として返すこともできます。使いかたの実例は `sfProjectDeployTask` クラスで見つかります。 ### `task.test.filter_test_files` -`test:*` タスクは自分自身が実行される前に `task.test.filter_test_files` イベントを通るようになりました。このイベントには `arguments` と `options` パラメータが用意されています。 +`test:*` タスクは自分自身が実行される前に `task.test.filter_test_files` イベントを通過するようになりました。このイベントのために `arguments` と `options` パラメータが用意されています。 ### `sfTask::run()` の強化 -`sfTask:run()` は次のような引数とオプションの連想配列をとるようになりました: +`sfTask:run()` メソッドは次のような引数とオプションからなる連想配列をとるようになりました。 [php] $task = new sfDoctrineConfigureDatabaseTask($this->dispatcher, $this->formatter); @@ -419,7 +421,7 @@ Propel もしくは Doctrine のどちらも使いたくなければ、`--orm` array('name' => 'master') ); -以前のバージョンでは、次のように書けばまだ動きます: +以前のバージョンでは、コードは次のように書きます。 [php] $task->run( @@ -429,14 +431,14 @@ Propel もしくは Doctrine のどちらも使いたくなければ、`--orm` ### `sfBaseTask::setConfiguration()` -PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run()` に `--application` と `--env` オプションを指定する必要はもはやありません。その代わり、`->setConfiguration()` を呼び出すだけで、設定オブジェクトを直接セットすることができます: +`sfBaseTask` クラスを継承するタスクを呼び出すとき、`->run()` メソッドのなかで `--application` と `--env` オプションを指定する必要はなくなりました。代わりに、`->setConfiguration()` メソッドを直接呼び出すだけで、コンフィギュレーションオブジェクトを設定できます。 [php] $task = new sfDoctrineLoadDataTask($this->dispatcher, $this->formatter); $task->setConfiguration($this->configuration); $task->run(); -以前のバージョンでは、次のように書けばまだ動きます: +以前のバージョンでは、コードを次のように書けばまだ動きます。 [php] $task = new sfDoctrineLoadDataTask($this->dispatcher, $this->formatter); @@ -447,35 +449,35 @@ PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run() ### `project:disable` と `project:enable` -`project:disable` と `project:enable` タスクを使うことで、環境全体を無効もしくは有効にできるようになりました: +`project:disable` と `project:enable` タスクを使うことで、環境全体を無効もしくは有効にすることができるようになりました。 $ php symfony project:disable prod $ php symfony project:enable prod -特定の環境において、どのアプリケーションを無効にするかを指定することもできます: +無効にするアプリケーションを環境ごとに指定することもできます。 $ php symfony project:disable prod frontend backend $ php symfony project:enable prod frontend backend -これらのタスクは従来の機能と後方互換性があります: +これらのタスクは従来の機能と後方互換性があります。 $ php symfony project:disable frontend prod $ php symfony project:enable frontend prod ### `help` と `list` -`help` と `list` タスクは情報を XML 形式で表示できるようになりました: +`help` と `list` タスクの出力形式に XML を選べるようになりました。 $ php symfony list --xml $ php symfony help test:all --xml -この出力はこのタスクオブジェクトの XML 表現を返す新しい `sfTask::asXml()` メソッドによるものです。 +これは新たに導入された `sfTask::asXml()` メソッドによるもので、このメソッドはタスクオブジェクトの XML 表現を返します。 -ほとんどの場合において、XML 出力は IDE のようなサードパーティに重宝するでしょう。 +XML は IDE などを開発するサードパーティに役立つでしょう。 ### `project:optimize` -このタスクを実行すると、アプリケーションにおけるテンプレートファイルの保存場所がキャッシュされ、実行時におけるディスクの読み込み回数が減ります。このタスクを使う場所は運用サーバーに限定すべきです。プロジェクトを変更するたびにタスクを再実行することをお忘れなく: +このタスクを実行すると、アプリケーションにおけるテンプレートファイルの保存場所がキャッシュされ、実行時においてディスクの読み込み回数が減ります。このタスクを使う場所は運用サーバーにとどめておくべきです。プロジェクトを変更するたびにタスクを再実行することをお忘れなく。 $ php symfony project:optimize frontend @@ -485,18 +487,18 @@ PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run() ### タスクからメールを送信する -`getMailer()` メソッドを使うことで、タスクからメールを簡単に送信できるようになりました。 +`getMailer()` メソッドが導入され、タスクからメールを送信しやすくなりました。 ### タスクでルーティングを使う -`getRouting()` メソッドを使うことで、タスクからルーティングオブジェクトを簡単に得られるようになりました。 +`getRouting()` メソッドが導入され、タスクからルーティングオブジェクトを取得しやすくなりました。 例外 ---- ### オートローディング -オートロードのあいだに例外が投げられるとき、symfony はこれらの例外を捕まえ、エラーをユーザーに出力します。この対応によっていくつかの「真っ白な」ページの問題が解決されます。 +オートロードのあいだに例外が投げられるとき、symfony はこれらの例外を捕まえて、ユーザーにエラーを報告するようになりました。この措置によって、いくつかの「真っ白な」ページの問題が解決されました。 ### デバッグツールバー @@ -505,32 +507,32 @@ PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run() Propel との統合 --------------- -Propel のバージョンは 1.4 にアップグレードされました。詳しいアップグレード情報に関しては[公式サイト](http://www.propelorm.org/wiki/Documentation/1.4)を訪問してくださるようお願いします。 +Propel のバージョンは1.4にアップグレードされました。アップグレードのくわしい手順については、[公式サイト](http://www.propelorm.org/wiki/Documentation/1.4)をご参照ください。 ### Propel のビヘイビア -Propel を拡張するために symfony が依存するカスタムのビルダークラスは Propel 1.4 の新しいビヘイビアシステムに移植されました。 +Propel を拡張するためのビルダークラスは Propel 1.4 の新しいビヘイビアシステムに移植されました。 ### `propel:insert-sql` -`propel:insert-sql` はデータベースからすべてのデータを削除する前に本当に実行してよいのか確認を求めてきます。。このタスクは、複数のデータベースからデータを削除するだけでなく、関連するデータベースコネクションの名前も表示するようになりました。 +`propel:insert-sql` タスクはデータベースからすべてのデータを削除する前に本当に実行してよいのかたずねてきます。このタスクは、複数のデータベースからデータを削除するだけでなく、関連するデータベースコネクションの名前を表示するようになりました。 ### `propel:generate-module`、`propel:generate-admin`、`propel:generate-admin-for-route` -`propel:generate-module`、`propel:generate-admin` と `propel:generate-admin-for-route` タスクに `--actions-base-class` オプションが導入され、生成モジュールのアクション基底クラスのコンフィギュレーションを変更できるようになりました。 +`--actions-base-class` オプションが `propel:generate-module`、`propel:generate-admin` と `propel:generate-admin-for-route` タスクに導入され、生成モジュールにおいて、アクションの基底クラスのコンフィギュレーションを変更できるようになりました。 ### Propel のビヘイビア -Propel 1.4 はビヘイビアの実装を導入しました。カスタムの symfony ビルダーはこの新しいシステムに移植されました。 +Propel 1.4 にビヘイビアが導入されました。そして、専用のビルダークラスはこの新しいシステムに移植されました。 -Propel モデルネイティブなビヘイビアを Propel モデルに追加したければ、`schema.yml` でも可能です: +`schema.yml` ファイルのなかで Propel モデルネイティブなビヘイビアを追加できます。 classes: Article: propel_behaviors: timestampable: ~ -もしくは `schema.yml` の古い構文を使うのであれば、次のように表記します: +古い構文を使うのであれば、次のように書きます。 propel: article: @@ -539,7 +541,7 @@ Propel モデルネイティブなビヘイビアを Propel モデルに追加 ### フォーム生成を無効にする -Propel の `symfony` ビヘイビアにパラメータを渡すことで、特定のモデルでのフォーム生成を無効にできます: +特定のモデルにおいて、フォーム生成を無効にするには、Propel の `symfony` ビヘイビアに次のパラメータを渡します。 classes: UserGroup: @@ -548,11 +550,11 @@ Propel の `symfony` ビヘイビアにパラメータを渡すことで、特 form: false filter: false -この設定が反映される前に、モデルを再構築しなければならないことにご注意ください。ふるまいが存在するようになるのはふるまいが添付されているモデルが再構築された後であるからです。 +設定の変更を反映させるために、モデルを再構築しなければならないことにご注意ください。ビヘイビアが存在するようになるのは、ビヘイビアが添付されているモデルが再構築された後であるからです。 -### Propel の異なるバージョンを使う +### Propel の異なるバージョンに切り替える - Propel の異なるバージョンを使うのは簡単で、必要なのは `ProjectConfiguration` のなかで設定変数の `sf_propel_runtime_path` と `sf_propel_generator_path` をセットするだけです: + Propel の異なるバージョンに切り替えることはかんたんです。必要なのは `ProjectConfiguration` クラスのなかで `sf_propel_runtime_path` と `sf_propel_generator_path` 設定変数にパスをセットするだけです。 [php] // config/ProjectConfiguration.class.php @@ -569,11 +571,11 @@ Propel の `symfony` ビヘイビアにパラメータを渡すことで、特 ### デフォルトの要件 -`column` オプションの値がデフォルトの `id` であるとき、デフォルトの必須要件の `\d+` は `sfObjectRouteCollection` にだけ適用されるようになりました。このことが意味するのは、(`slug` のような) 数字ではないカラムが指定されているときに代わりの必須要件を用意する必要はないということです。 +`column` オプションにセットされている値がデフォルトの `id` である場合、デフォルトの必須要件の `\d+` は `sfObjectRouteCollection` クラスだけに適用されるようになりました。このことが意味するのは、(`slug` のように) 数字ではないカラムが指定されていれば、代わりの必須要件を用意する必要はないということです。 -### `sfObjectRouteCollection` オプション +### `sfObjectRouteCollection` のオプション -`sfObjectRouteCollection` に新しい `default_params` オプションが導入されました。このオプションによって生成されるルートごとにデフォルトパラメータを登録できます: +`sfObjectRouteCollection` クラスに `default_params` オプションが新たに導入され、ルートごとにデフォルトパラメータを登録できるようになりました。 [yml] forum_topic: @@ -587,37 +589,37 @@ CLI ### カラー出力 -symfony CLI を使うとき、symfony はお使いのコンソールがカラー出力をサポートしているかどうかを推測します。ただし、たとえば Cygwin を使っている場合には推測が間違うことがあります (Windows プラットフォームではカラー出力がつねにオフだからです)。 +symfony CLI を使うとき、symfony は使っているコンソールがカラー出力をサポートしているかどうかを推測します。ただし、たとえば Cygwin を使っている場合には推測がまちがっている可能性があります (Windows プラットフォームではカラー出力がつねにオフだからです)。 -symfony 1.3/1.4 では、グローバルオプションの `--color` を渡すことで、カラー出力を強制できるようになりました。 +グローバルオプションの `--color` を渡して、カラー出力を強制できるようになりました。 -国際化対応 ------------ +国際対応 +--------- ### データの更新 -国際化対応オペレーションに使われているすべてのデータは `ICU` プロジェクトから更新されました。symfony には約330個のロケールファイルが付属しており、symfony 1.2 と比べると約70個増えました。ですので、たとえば、言語リストの10番目の項目をチェックするテストケースが通らない可能性があることにご注意ください。 +国際対応オペレーションに使われる `ICU` プロジェクトからのデータはすべて更新されました。symfony には約330個のロケールファイルが収められており、symfony 1.2 と比べると約70個増えました。ですので、たとえば、言語リストの10番目の項目をチェックするテストケースが通らない可能性があることにご注意ください。 ### ユーザーロケールを基準にソートする -ユーザーロケールに依存するデータのソートもすべてロケールに依存して実行されるようになりました。`sfCultureInfo->sortArray()` はこの用途に使うことができます。 +ユーザーロケールに依存するデータのソートもすべてロケールに依存して実行されるようになりました。`sfCultureInfo` クラスの `sortArray()` メソッドはこの用途に使うことができます。 プラグイン ---------- -symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin` 以外のすべてのプラグインがデフォルトで有効でした: +symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin` 以外のすべてのプラグインがデフォルトで有効でした。 [php] class ProjectConfiguration extends sfProjectConfiguration { public function setup() { - // 互換性のために必要なプラグインだけ削除および有効にする + // 互換性のために必要なプラグインだけ有効にします $this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin')); } } -symfony 1.3/1.4 の新しいプロジェクトでプラグインを有効にするには、`ProjectConfiguration` クラスのなかで明確に記述しなければなりません: +symfony 1.3/1.4 で新しいプロジェクトでプラグインを有効にするには、`ProjectConfiguration` クラスのなかで明確に宣言しなければなりません。 [php] class ProjectConfiguration extends sfProjectConfiguration @@ -628,16 +630,16 @@ symfony 1.3/1.4 の新しいプロジェクトでプラグインを有効にす } } -`plugin:install` タスクはインストールするプラグインを自動的に有効にします (そして `plugin:uninstall` はプラグインを無効にします)。Subversion 経由でプラグインをインストールする場合、手動で有効にする必要があります。 +`plugin:install` タスクはインストールするプラグインを自動的に有効にします (そして `plugin:uninstall` タスクはプラグインを無効にします)。Subversion を通じてプラグインをインストールする場合、手動で有効にする必要があります。 -`sfProtoculousPlugin` もしくは `sfCompat10Plugin` のようなコアプラグインを使いたければ、必要なのは対応する `enablePlugins()` メソッドを `ProjectConfiguration` クラスに追加することだけです。 +`sfProtoculousPlugin` もしくは `sfCompat10Plugin` のようなコアプラグインを使うのであれば、必要なのは `ProjectConfiguration` クラスのなかで `enablePlugins()` メソッドを呼び出すだけです。 >**NOTE** ->symfony 1.2 からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが `ProjectConfiguration` ファイルを変更しないからです。新しいふるまいが適用されるのは symfony 1.3/1.4 の新規プロジェクトだけです。 +>symfony 1.2 からプロジェクトをアップグレードする場合、古いふるまいは有効な状態に保たれます。これはアップグレードタスクが `ProjectConfiguration` クラスのファイルを変更しないからです。新しいふるまいが適用されるのは symfony 1.3/1.4 の新規プロジェクトにかぎられます。 ### `sfPluginConfiguration::connectTests()` -新しい `setupPlugins()` メソッドのなかでプラグインコンフィギュレーションの `->connectTests()` メソッドを呼び出すことで、プラグインのテストを `test:*` タスクに結びつけることができます: +新たに導入された `setupPlugins()` メソッドのなかでプラグインコンフィギュレーションの `->connectTests()` メソッドを呼び出せば、プラグインのテストを `test:*` タスクに結びつけることができます。 [php] class ProjectConfiguration extends sfProjectConfiguration @@ -653,9 +655,9 @@ symfony 1.3/1.4 の新しいプロジェクトでプラグインを有効にす ### `sf_file_link_format` -`sf_file_link_format` がセットされていれば、symfony はファイルパスをクリック可能なリンクの形式 (すなわちデバッグ例外のテンプレート) に整え、セットされていなければ、symfony は PHP コンフィギュレーションの `xdebug.file_link_format` の値を探すようになりました。 +`sf_file_link_format` 設定に値がセットされていれば、symfony はファイルパスをクリック可能なリンクの形式 (すなわちデバッグ例外のテンプレート) に整え、値がセットされていなければ、symfony は PHP コンフィギュレーションの `xdebug.file_link_format` ディレクティブの値を探すようになりました。 -たとえば、ファイルを TextMate で開きたいのであれば、`settings.yml` に次のコードを追加します: +たとえば、ファイルを TextMate で開くには、`settings.yml` ファイルで次のコードを書き加えます。 [yml] all: @@ -667,13 +669,13 @@ symfony 1.3/1.4 の新しいプロジェクトでプラグインを有効にす Doctrine との統合 ----------------- -Doctrine のバージョンは 1.2 にアップグレードされました。アップグレードに関する詳しい情報は [Doctrine の公式サイト](http://www.doctrine-project.org/documentation/1_2/ja)を訪問してくださるようお願いします。 +Doctrine のバージョンは1.2にアップグレードされました。アップグレードのくわしい手順については、[Doctrine の公式サイト](http://www.doctrine-project.org/documentation/1_2/ja)をご参照ください。 ### フォームクラスを生成する -Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そしてフォームとフィルタクラスの生成を無効にするオプションもいくつか導入されました。 +Doctrine の YAML スキーマファイルのなかで symfony の追加オプションを指定できるようになりました。そして、フォームとフィルタクラスの生成を無効にするオプションもいくつか導入されました。 -たとえば典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので次のように書くことができます: +たとえば典型的な多対多のリファレンスモデルでは、フォームもしくはフィルタフォームクラスを生成させる必要はありません。ですので、スキーマを次のように書くことができます。 UserGroup: options: @@ -690,57 +692,57 @@ Doctrine の YAML スキーマファイルのなかで symfony の追加オプ ### フォームクラスの継承 -モデルクラスからフォームを生成するとき、モデルクラスは継承を含んでいます。生成される子クラスは継承を尊重し、同じ継承構造にもとづくフォームを生成します。 +モデルクラスからフォームが生成される場合、生成される子クラスにはモデルクラスの継承関係が反映され、同じ継承構造にしたがうフォームが生み出されます。 ### 新しいタスク -Doctrine で開発するときに支援してくれる新しいタスクが導入されました。 +Doctrine で開発するときに役立つタスクが新たに導入されました。 #### モデルテーブルを作る -指定モデルの配列に対応するテーブルを個別に作ることができるようになりました。Doctrine はテーブルを削除した後で、あなたに代わってテーブルを再構築してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を消去せずにテーブル群を再構築する際に役立ちます: +指定されたモデルの配列に対応するテーブルを個別に作れるようになりました。Doctrine はテーブルを削除した後で、あなたに代わってテーブルを再構築してくれます。既存のプロジェクト/データベースで新しいモデルを開発していて、データベース全体を消去せずにテーブル群を再構築する際に役立ちます。 $ php symfony doctrine:create-model-tables Model1 Model2 Model3 #### モデルファイルを削除する -YAML スキーマファイルのなかで、モデルのコードや名前を変更したり、使わなくなったモデルを削除することがよくあります。このような作業を行うと、孤児になったモデル、フォームそしてフィルタクラスが出てきます。`doctrine:delete-model-files` タスクを使うことで、モデルに関連する生成ファイルを手作業で削除できるようになりました: +YAML スキーマファイルのなかで、モデルのコードや名前を変更したり、使わなくなったモデルを削除することがよくあります。このような作業をおこなうと、孤児となったモデル、フォームそしてフィルタクラスが発生します。`doctrine:delete-model-files` タスクを使って、モデルに関連する生成ファイルを手作業で削除できるようになりました。 $ php symfony doctrine:delete-model-files ModelName -上記のタスク実行では、タスクは関連する生成ファイルを見つけ、そのファイルを削除したいかどうか確認を求めてきます。 +上記の例では、タスクは関連する生成ファイルを見つけ、削除してよいかたずねてきます。 -#### モデルファイルをきれいにする +#### モデルファイルをお掃除する -上記のプロセスを `doctrine:clean-model-files` タスクで自動化することで、ディスクに存在するが YAML スキーマファイルには存在しないモデルを見つけることができます: +`doctrine:clean-model-files` タスクを実行すれば、上記のプロセスを自動化して、ディスクに存在するが YAML スキーマファイルには存在しないモデルを見つけることができます。 $ php symfony doctrine:clean-model-files -上記のコマンドは YAML スキーマファイルと生成モデルやファイルを比較し、どれを削除するのかを決めます。これらのモデルは `doctrine:delete-model-files` タスクに渡されます。タスクは、ファイルを自動的に削除する前に本当に実行してよいのか確認を求めてきます。 +上記のコマンドは YAML スキーマファイルと生成モデルやファイルを比較し、どれを削除するのかを決めます。これらのモデルは `doctrine:delete-model-files` タスクに渡されます。タスクは、ファイルを自動的に削除する前に本当に実行してよいのかたずねてきます。 #### 何でもビルドする -新しく用意された `doctrine:build` タスクによって symfony や Doctrine にビルドしてほしいものを明確に指定できます。このより柔軟性のある解決方法に合わせて、廃止予定になった既存の多くのタスクを組み合わせて得られる機能はこのタスクによって再現できます。 +`doctrine:build` タスクが新たに導入され、symfony や Doctrine にビルドさせたいものを明確に指定できるようになりました。この柔軟性のある解決策が取り込まれたことにともない、さまざまなタスクが廃止予定になりましたが、これらのタスクを組み合わせて得られる機能はこのタスクによって再現できます。 -`doctrine:build` の使い方は次のとおりです: +`doctrine:build` タスクの使いかたは次のようになります。 $ php symfony doctrine:build --db --and-load -この例では、データベースを削除してから (`:drop-db`)、作成し (`:build-db`)、`schema.yml` のなかで設定されているテーブルを作成し (`:insert-sql`)、フィクスチャデータをロードします (`:data-load`): +上記の例では、データベースを削除してから (`:drop-db`)、作り直し (`:build-db`)、`schema.yml` ファイルのなかで設定されているテーブルを作り (`:insert-sql`)、フィクスチャデータをロードします (`:data-load`)。 $ php symfony doctrine:build --all-classes --and-migrate -この例では、モデル (`:build-model`)、フォーム (`:build-forms`)、フォームフィルタ (`:build-filters`) を生成し、保留されているマイグレーション (`:migrate`) を実行します: +上記の例では、モデル (`:build-model`)、フォーム (`:build-forms`)、フォームフィルタ (`:build-filters`) を生成し、保留されているマイグレーション (`:migrate`) を実行します。 $ php symfony doctrine:build --model --and-migrate --and-append=data/fixtures/categories.yml -この例では、モデルを生成 (`:build-model`) し、データベースのマイグレーション (`:migrate`) を実行し、そしてカテゴリのフィクスチャデータ (`:data-load --append --dir=/data/fixtures/categories.yml`)をつけ加えます。 +上記の例では、モデルを生成し (`:build-model`)、データベースのマイグレーションを実行し (`:migrate`)、そしてカテゴリのフィクスチャデータをつけ加えます (`:data-load --append --dir=/data/fixtures/categories.yml`)。 -詳しい情報は `doctrine:build` タスクのヘルプページを参照してください。 +くわしい説明は `doctrine:build` タスクのヘルプページをご参照ください。 #### 新しいオプション: `--migrate` -次のタスクは `--migrate` オプションを受け取るようになり、入れ子の `doctrine:insert-sql` タスクを `doctrine:migrate` に置き換えます。 +次の一連のタスクは `--migrate` オプションを受けつけるようになりましたので、ネストの `doctrine:insert-sql` タスクを `doctrine:migrate` タスクに置き換えます。 * `doctrine:build-all` * `doctrine:build-all-load` @@ -751,51 +753,50 @@ YAML スキーマファイルのなかで、モデルのコードや名前を変 #### `doctrine:generate-migration --editor-cmd` -`doctrine:generate-migration` タスクは `--editor-cmd` オプションを受け取るようになりました。このオプションは編集を楽にするために用意され、マイグレーションクラスが作られるときに実行されます: - +`doctrine:generate-migration` タスクに `--editor-cmd` オプションが導入され、生成されたマイグレーションクラスを編集しやすくなりました。 $ php symfony doctrine:generate-migration AddUserEmailColumn --editor-cmd=mate -この例では、マイグレーションクラスが生成され、新しいファイルが TextMate で開かれます。 +上記の例では、マイグレーションクラスが生成され、新しいファイルが TextMate で開かれます。 #### `doctrine:generate-migrations-diff` -この新しいタスクは、新旧のスキーマをもとに完全なマイグレーションクラスを自動的に生成します。 +新たに導入されたこのタスクは、新旧のスキーマをもとに完全なマイグレーションクラスを自動的に生成します。 #### 特定のコネクションを作成もしくは削除する -`doctrine:build-db` と `doctrine:drop-db` を実行する際に、データベースのコネクションを指定できるようになりました: +`doctrine:build-db` と `doctrine:drop-db` タスクを実行する際に、データベースコネクションを指定できるようになりました。 $ php symfony doctrine:drop-db master slave1 slave2 ### 日付のセッターとゲッター -2つのメソッドが新たに導入され、Doctrine の日付とタイムスタンプの値を PHP の DateTime オブジェクトインスタンスとして取得できるようになりました: +2つのメソッドが新たに導入され、Doctrine の日付とタイムスタンプの値を PHP の DateTime インスタンスとして取得できるようになりました。 [php] echo $article->getDateTimeObject('created_at') ->format('m/d/Y'); -`setDateTimeObject` メソッドを呼び出し、有効な `DateTime` インスタンスを渡すだけで、日付の値もセットできます: +`setDateTimeObject()` メソッドを呼び出し、有効な `DateTime` インスタンスを渡すだけで、日付の値もセットできます。 [php] $article->setDateTimeObject('created_at', new DateTime('09/01/1985')); ### `doctrine:migrate --down` -`doctrine:migrate` は `up` と `down` オプションを受け取るようになりました。これらのオプションをつければ、スキーマがリクエストされる方向に1回でマイグレートされます: +`doctrine:migrate` タスクは `--up` と `--down` オプションを受けつけるようになりました。これらのオプションをつければ、スキーマがリクエストされる方向に1回でマイグレートされます。 $ php symfony doctrine:migrate --down ### `doctrine:migrate --dry-run` -データベースが DDL 文のロールバックをサポートする場合 (MySQL はサポートしません)、新しい `dry-run` オプションを指定できます: +データベースが DDL 文のロールバックをサポートしている場合 (MySQL はサポートしていません)、新たに導入された `--dry-run` オプションをつけることができます。 $ php symfony doctrine:migrate --dry-run -### DQL タスクを表形式のデータとして出力する +### DQL タスクにおいて表をデータ出力形式に選ぶ -`doctrine:dql` コマンドを実行するとき、従来のデータ出力形式は YAML だけでした。新しく導入された `--table` オプションによって MySQL のコマンドライン出力と似た表形式でもデータを出力できるようになりました。そのため、次のような表現ができるようになりました: +`doctrine:dql` タスクに `--table` オプションが新たに導入され、データ出力形式の選択肢として、従来の YAML に加えて MySQL のコマンドライン出力と似た表形式も追加されました。 $ ./symfony doctrine:dql "FROM Article a" --table >> doctrine executing dql query @@ -810,13 +811,13 @@ YAML スキーマファイルのなかで、モデルのコードや名前を変 ### `doctrine:dql` にクエリパラメータを渡す -`doctrine:dql` タスクはクエリパラメータも引数にとるように強化されました: +`doctrine:dql` タスクはクエリパラメータも引数にとるように強化されました。 $ php symfony doctrine:dql "FROM Article a WHERE name LIKE ?" John% -### 機能テストでクエリをデバッグする +### 機能テストのなかでクエリをデバッグする -`sfTesterDoctrine` クラスに `->debug()` メソッドが導入されました。このメソッドは現在のコンテキストで実行されたクエリの情報を出力します: +`sfTesterDoctrine` クラスに `->debug()` メソッドが新たに導入されました。このメソッドは現在のコンテキストで実行されたクエリの情報を出力します。 [php] $browser-> @@ -824,7 +825,7 @@ YAML スキーマファイルのなかで、モデルのコードや名前を変 with('doctrine')->debug() ; -メソッドに数値を渡せば、少し前に実行されたクエリの履歴が表示され、文字列を渡せば、文字列の一部にマッチするクエリや正規表現にマッチするクエリだけが表示されます: +メソッドに数値を渡せば、少し前に実行されたクエリの履歴が表示され、文字列を渡せば、文字列の一部にマッチするクエリや正規表現にマッチするクエリだけが表示されます。 [php] $browser-> @@ -834,35 +835,35 @@ YAML スキーマファイルのなかで、モデルのコードや名前を変 ### `sfFormFilterDoctrine` -`sfFormFilterDoctrine` クラスは `query` オプションを通して `Doctrine_Query` のシードを提供できるようになりました: +`sfFormFilterDoctrine` のインスタンス作成時において `query` オプションを通じて `Doctrine_Query` のシードを提供できるようになりました。 [php] $filter = new ArticleFormFilter(array(), array( 'query' => $table->createQuery()->select('title, body'), )); -`->setTableMethod()` (もしくは `table_method` オプション) を通して指定されるテーブルメソッドはクエリオブジェクトを返す必要がありません。次のコードはどれも有効な `sfFormFilterDoctrine` テーブルメソッドです: +`->setTableMethod()` メソッド (もしくは `table_method` オプション) を通じて指定されたテーブルメソッドはクエリオブジェクトを返す必要はありません。次のコードはどれも有効な `sfFormFilterDoctrine` のテーブルメソッドです。 [php] - // symfony >= 1.2 で動く + // symfony 1.2 およびそれ以降で動きます public function getQuery() { return $this->createQuery()->select('title, body'); } - // symfony >= 1.2 で動く + // symfony 1.2 およびそれ以降で動きます public function filterQuery(Doctrine_Query $query) { return $query->select('title, body'); } - // symfony >= 1.3 で動く + // symfony 1.3 およびそれ以降で動きます public function modifyQuery(Doctrine_Query $query) { $query->select('title, body'); } -フォームフィルタのカスタマイズが簡単になりました。フィールドにフィルタリングを追加するために必要なのは、ウィジェットとそれを処理するメソッドを追加することだけです: +フォームフィルタをカスタマイズしやすくなりました。フィールドにフィルタをかけるために必要なのは、ウィジェットとそれを処理するメソッドを書き加えることだけです。 [php] class UserFormFilter extends BaseUserFormFilter @@ -882,23 +883,23 @@ YAML スキーマファイルのなかで、モデルのコードや名前を変 } } -以前のバージョンでこのコードを動くようにするには、ウィジェットとメソッドを作ることに加えて、`getFields()` を拡張する必要がありました。 +以前のバージョンでこのコードを動くようにするには、ウィジェットとメソッドを作ることに加えて、`getFields()` メソッドを拡張する必要がありました。 ### Doctrine のコンフィギュレーションを変更する -Doctrine のコンフィギュレーションを変更するために、`doctrine.configure` と `doctrine.configure_connection` イベントをリスニングできます。このことが意味するのは、`sfDoctrinePlugin` よりも優先される場所でプラグインを有効にしているかぎり、プラグインから Doctrine のコンフィギュレーションをカスタマイズするのは簡単であるということです。 +`doctrine.configure` と `doctrine.configure_connection` イベントをリスニングしていれば、Doctrine のコンフィギュレーションを変更できます。このことが意味するのは、プラグインを有効にする場所が `sfDoctrinePlugin` クラスよりも優先される場所であるかぎり、プラグインから Doctrine のコンフィギュレーションをカスタマイズするのはかんたんであるということです。 ### `doctrine:generate-module`、`doctrine:generate-admin`、`doctrine:generate-admin-for-route` -`doctrine:generate-module`、`doctrine:generate-admin`、`doctrine:generate-admin-for-route` タスクに `--actions-base-class` オプションが導入され、生成モジュールにおけるアクション基底クラスのコンフィギュレーションを変更できるようになりました。 +`--actions-base-class` オプションが `doctrine:generate-module`、`doctrine:generate-admin`、`doctrine:generate-admin-for-route` タスクに導入され、生成モジュールにおいて、アクションの基底クラスのコンフィギュレーションを変更できるようになりました。 ### マジックメソッドの PHPDoc タグ -symfony によって Doctrine モデルに追加されるマジックメソッドのゲッターとセッターは、それぞれの生成基底クラスの PHPDoc ヘッダーに現れます。IDE がコード入力補完をサポートする場合、これらの `getFooBar()` と `setFooBar()` メソッドはモデルオブジェクトで見つかります。`FooBar` はラクダ記法のフィールド名です。 +symfony によって Doctrine モデルに追加されるマジックメソッドのゲッターとセッターは生成された基底クラスの PHPDoc ヘッダーにあらわれます。IDE がコード入力補完をサポートしている場合、これらの `getFooBar()` と `setFooBar()` メソッドはモデルオブジェクトで見つかります。`FooBar` はキャメルケースのフィールド名です。 -### Doctrine の異なるバージョンを使う +### Doctrine の異なるバージョンに切り替える -Doctrine の異なるバージョンを使うのは簡単で、必要なのは `ProjectConfiguration` のなかで `sf_doctrine_dir` 設定をセットするだけです: +Doctrine の異なるバージョンに切り替えるのはかんたんで、必要なのは `ProjectConfiguration` クラスのなかで `sf_doctrine_dir` 設定変数にパスをセットするだけです。 [php] // config/ProjectConfiguration.class.php @@ -910,17 +911,17 @@ Doctrine の異なるバージョンを使うのは簡単で、必要なのは ` } デバッグツールバー -------------------------- +------------------ ### `sfWebDebugPanel::setStatus()` -デバッグツールバーにおいて、タイトルの背景色に影響を与えるステータスをパネルごとに指定できるようになりました。たとえば、`sfLogger::INFO` よりも優先順位が高いメッセージがロギングされている場合、log パネルのタイトルの背景色は変わります。 +デバッグツールバーにおいて、タイトルの背景色に影響を及ぼすステータスをパネルごとに指定できるようになりました。たとえば、`sfLogger::INFO` よりも優先順位が高いメッセージがログに記録されている場合、log パネルのタイトルの背景色は変わります。 ### `sfWebDebugPanel` リクエストパラメータ -`sfWebDebugPanel` パラメータを URL につけ足すことで、ページをロードするときに開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を付け足せば、config パネルが開いた状態になるように、デバッグツールバーはレンダリングされます。 +URL に `sfWebDebugPanel` パラメータをつけ足せば、ページをロードするときに開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` をつけ足せば、config パネルが開いた状態になるように、デバッグツールバーはレンダリングされます。 -デバッグツールバーの `request_parameters` オプションにアクセスすることで、パネルはリクエストパラメータをインスペクトします: +パネルはデバッグツールバーの `request_parameters` オプションにアクセスして、リクエストパラメータを検査します。 [php] $requestParameters = $this->webDebug->getOption('request_parameters'); @@ -930,16 +931,16 @@ Doctrine の異なるバージョンを使うのは簡単で、必要なのは ` ### スロットの改善 -スロットが提供されない場合、`get_slot()` と `include_slot()` ヘルパーは第2引数に渡されたスロットのデフォルト内容を返します: +スロットが提供されていなければ、`get_slot()` と `include_slot()` ヘルパーは第2引数に渡されたスロットのデフォルト内容を返すようになりました。 [php] - - + + ページャ --------- -`sfDoctrinePager` と `sfPropelPager` メソッドは `Iterator` と `Countable` インターフェイスを実装するようになりました: +`sfDoctrinePager` と `sfPropelPager` クラスは `Iterator` と `Countable` インターフェイスを実装するようになりました。
    @@ -954,17 +955,17 @@ Doctrine の異なるバージョンを使うのは簡単で、必要なのは ` ビューキャッシュ ----------------- -ビューキャッシュマネージャは `factories.yml` のなかのパラメータを受け取ります。ビューのキャッシュキーの生成方法がリファクタリングされ、クラスを異なる方法で簡単に拡張できるようになりました。 +ビューキャッシュマネージャは `factories.yml` ファイルのなかのパラメータを受けとるようになりました。ビューのキャッシュキーの生成方法がリファクタリングされ、クラスを異なる方法でかんたんに拡張できるようになりました。 -`factories.yml` で2つのパラメータが利用できます: +`factories.yml` ファイルのなかで2つのパラメータが利用できます。 - * `cache_key_use_vary_headers` (デフォルト: true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実際には、`vary` キャッシュパラメータで指定されるので、このパラメータはページキャッシュが HTTP ヘッダーに依存するかどうかを伝えます。 + * `cache_key_use_vary_headers` (デフォルトは true): キャッシュキーが Vary ヘッダーの一部を含むか指定します。実例として、`vary` キャッシュパラメータのなかで指定することで、ページキャッシュが HTTP ヘッダーに依存しているのかどうかを伝えるのに使われていることがあげられます。 - * `cache_key_use_host_name` (デフォルト: true): キャッシュキーがホスト名の部分を含むか指定します。実際には、このパラメータはページキャッシュがホスト名に依存するかどうかを伝えます。 + * `cache_key_use_host_name` (デフォルトは true): キャッシュキーがホスト名の部分を含むか指定します。実例として、ページキャッシュをホスト名に依存しているかどうかを伝えることに使われていることがあげられます。 ### キャッシュの強化 -ビューキャッシュマネージャはスーパーグローバルの `$_GET` もしくは `$_POST` に値が存在するのかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` をチェックする前の GET リクエストメソッドであることを確認するだけです。このことが意味するのは、次のページをキャッシュできるようになったということです: +ビューキャッシュマネージャはスーパーグローバルの `$_GET` もしくは `$_POST` に値が存在しているのかどうかによってキャッシュを拒否しなくなりました。ロジックは現在のリクエストが `cache.yml` ファイルをチェックする前の GET リクエストメソッドであることを確認するだけです。このことが意味するのは、次のページをキャッシュできるようになったということです。 * `/js/my_compiled_javascript.js?cachebuster123` * `/users?page=3` @@ -974,18 +975,18 @@ Doctrine の異なるバージョンを使うのは簡単で、必要なのは ` ### `getContent()` -リクエストの内容は `getContent()` メソッドを通してアクセスできるようになりました。 +`getContent()` メソッドを通じてリクエストの内容にアクセスできるようになりました。 -### `PUT` と `DELETE` パラメータ +### `PUT` と `DELETE` メソッド -HTTP リクエストにおいて `PUT`、`DELETE` メソッドの Content-Type が `application/x-www-form-urlencoded` である場合、symfony は生のボディをパースし、通常の `POST` パラメータのようにアクセスできるパラメータを用意します。 +HTTP リクエストにおいて `PUT`、`DELETE` メソッドの Content-Type ヘッダーに `application/x-www-form-urlencoded` がセットされている場合、symfony は生のボディをパースし、通常の `POST` メソッドのようにアクセスできるパラメータを用意するようになりました。 アクション ---------- ### `redirect()` -`sfAction:redirect()` メソッドは symfony 1.2 で導入された `url_for()` メソッドのシグネチャと互換性をもつようになりました: +`sfAction:redirect()` メソッドは symfony 1.2 で導入された `url_for()` ヘルパーのシグネチャと互換性をもつようになりました。 [php] // symfony 1.2 @@ -994,14 +995,14 @@ HTTP リクエストにおいて `PUT`、`DELETE` メソッドの Content-Type // symfony 1.3/1.4 $this->redirect('article_show', $article); -この強化内容は `redirectIf()` と `redirectUnless()` にも適用されました。 +この強化内容は `redirectIf()` と `redirectUnless()` メソッドにも適用されました。 ヘルパー -------- ### `link_to_if()`、`link_to_unless()` -`link_to_if()` と `link_to_unless()` ヘルパーは symfony 1.2 で導入された `link_to()` メソッドのシグネチャと互換性をもつようになりました: +`link_to_if()` と `link_to_unless()` ヘルパーは symfony 1.2 で導入された `link_to()` ヘルパーのシグネチャと互換性をもつようになりました。 [php] // symfony 1.2 @@ -1013,7 +1014,7 @@ HTTP リクエストにおいて `PUT`、`DELETE` メソッドの Content-Type コンテキスト ----------- -`sfContext` による動的なメソッド追加を実現するために、`context.method_not_found` をリスニングできます。プラグインから遅延ロードファクトリを追加する際に役立ちます: +`context.method_not_found` イベントをリスニングしていれば、`sfContext` オブジェクトにメソッドを動的に追加できるようになりました。プラグインから遅延ロードファクトリを追加する際に役立ちます。 [php] class myContextListener diff --git a/tutorial/ja/which-version.markdown b/tutorial/ja/which-version.markdown index ee370e2..72a7835 100644 --- a/tutorial/ja/which-version.markdown +++ b/tutorial/ja/which-version.markdown @@ -1,14 +1,14 @@ どちらのバージョンを選べばよいのか？ -================================== +==================================== -symfony 1.3 と symfony 1.4 のドキュメントの内容はまったく同じです。2つの異なるバージョンに対してドキュメントが1つしかない状況はめったにないので、これから2つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をどのようにすればよいのかを説明します。 +symfony 1.3 と symfony 1.4 のドキュメントの内容はまったく同じです。2つの異なるバージョンがまったく同じドキュメントを共有する状況はめったにありませんので、これから2つのバージョンのあいだにどのような違いがあり、あなたのプロジェクトのために最善の選択をどのようにすればよいのかを説明します。 -symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年末) にリリースされ、実際のところ、これらのバージョンには両方とも**まったく同じ機能一式**が備わっています。2つのバージョンの唯一の違いは symfony の古いバージョンとの後方互換性のサポートです。 +symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年末) に公開され、実際のところ、両方のバージョンで用意されている一連の機能は**まったく同じ**です。2つのバージョンの唯一の違いは symfony の古いバージョンとの後方互換性のサポートです。 -古い symfony のバージョン (1.0、1.1 もしくは 1.2) を使うレガシープロジェクトをアップグレードするのであれば、symfony 1.3 を選びます。このバージョンには、廃止予定であるがまだ利用可能な後方互換性レイヤーとすべての機能が備わっています。このことが意味するのは、アップグレードが楽でシンプルであり、そして安全でもあるということです。 +symfony の古いバージョン (1.0、1.1もしくは1.2) を使うレガシープロジェクトをアップグレードするのであれば、symfony 1.3 を選びます。このバージョンには廃止予定であるがまだ利用可能な後方互換性レイヤーも備わっています。このことが意味するのは、アップグレードがかんたんで楽であり、そして安全でもあるということです。 -今日から新しいプロジェクトを始めるのであれば、symfony 1.4 を選びます。このバージョンには symfony 1.3 と同じ機能一式が備わっていますが、完全な後方互換性を含めて廃止予定の機能がすべて削除されています。このバージョンは symfony 1.3 よりもコードがきれいで少し速く動きます。symfony 1.4 を選ぶ別の大きな利点はサポート期間がより長いことで、symfony コアチームによって3年間メンテナンスされます (2012年11月まで)。 +今日から新しいプロジェクトをはじめるのであれば、symfony 1.4 を選びます。このバージョンに備わっている一連の機能は symfony 1.3 と同じですが、完全な後方互換性を含む廃止予定の機能がすべて削除されています。このバージョンは symfony 1.3 よりもコードがすっきりしており、少し速く動きます。symfony 1.4 を選ぶ別の大きな利点はサポート期間の長さです。symfony コアチームによって3年間メンテナンスされます (2012年11月まで)。 -もちろん、プロジェクトを symfony 1.3 にマイグレートして symfony 1.3 がサポートされる期間 (2010年11月まで) に廃止予定の機能を削除して、コードをゆっくりアップデートしてから、長期サポートの恩恵を受けるために、最終的に symfony 1.4 に移行するための時間は十分にあります。 +もちろん、プロジェクトを symfony 1.3 に移行してから、最終的に symfony 1.4 に移行することもできます。その場合には、symfony 1.3 がサポートされる期間 (2010年11月まで) に廃止予定の機能を削除してから、コードをゆっくりアップデートするための準備期間は充分にあります。 -このドキュメントでは、廃止予定の機能を説明しないので、すべての例は両方のバージョンで等しく動きます。 +このドキュメントでは、廃止予定の機能を説明しませんので、すべての例は両方のバージョンに適用できます。