Author: masaki
Date: 2010-03-25 08:44:47 +0100 (Thu, 25 Mar 2010)
New Revision: 28776
Modified:
doc/branches/1.4/tutorial/ja/deprecated.markdown
doc/branches/1.4/tutorial/ja/upgrade.markdown
doc/branches/1.4/tutorial/ja/whats-new.markdown
doc/branches/1.4/tutorial/ja/which-version.markdown
Log:
[doc-ja][1.4] slightly modified some sentences in the upgrade tutorials
Modified: doc/branches/1.4/tutorial/ja/deprecated.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-25 02:35:07 UTC
(rev 28775)
+++ doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-25 07:44:47 UTC
(rev 28776)
@@ -178,7 +178,7 @@
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」 (`data/web/calendar/` で見つかります) は symfony 1.4
で削除されます。このライブラリを使っていたのは symfony 1.4 で削除される Form ヘルパーグループだけだったからです。
symfony 1.3 に関して、サイトが利用不可能なときに表示されるページは `%SF_APP_CONFIG_DIR%/` と
`%SF_CONFIG_DIR%/` ディレクトリでのみ探されます。まだこのページを `%SF_WEB_DIR%/errors/`
に保存しているのであれば、symfony 1.4 へのマイグレーションを行う前に削除しなければなりません。
Modified: doc/branches/1.4/tutorial/ja/upgrade.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-25 02:35:07 UTC
(rev 28775)
+++ doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-25 07:44:47 UTC
(rev 28776)
@@ -13,13 +13,13 @@
(すべての廃止予定の機能が削除されていること以外) symfony 1.4 は symfony 1.3
と同じなので、このバージョンにアップグレードするタスクはありません。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`
>などのプロジェクトの設定ファイルでこれらのプラグインを明示的に無効にする場合、これらのファイルからこれらのプラグインの記述をすべて削除しなければなりません。
@@ -116,7 +116,7 @@
共通フィルタは複数の理由から削除されました:
- * シンプルでより柔軟ですぐれた解決方法がすでにあります (`include_stylesheets()` と
`include_javascripts()` ヘルパー)。
+ * よりシンプルで柔軟ですぐれた解決方法がすでにあります (`include_stylesheets()` と
`include_javascripts()` ヘルパー)。
* 最初にフィルタの存在を知らなければならず「背後」のマジックがはたらいているので、フィルタを無効にするタスクは簡単ではないからです。
@@ -130,7 +130,7 @@
* すべての `filters.yml` 設定ファイルから `common` フィルタを削除する必要があります (この作業は
`project:upgrade1.3` タスクによって自動的に行われます)。
- * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()`
呼び出しをレイアウトに追加する必要があります (この作業はアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の
`project:upgrade1.3` タスクによって自動的に行われます - これらのレイアウトには `<head>`
タグを収められていなければなりません; ほかのレイアウト、もしくはレイアウトをもたないが JavaScript
ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。
+ * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()`
呼び出しをレイアウトに追加する必要があります (この作業はアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の
`project:upgrade1.3` タスクによって自動的に行われます - これらのレイアウトには `<head>`
タグが収められていなければなりません; ほかのレイアウト、もしくはレイアウトをもたないが JavaScript
ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。
>**NOTE**
@@ -199,7 +199,7 @@
メーラー
--------
-symfony 1.3 には新しいメーラーファクトリが用意されています。アプリケーションが作られるとき、`factories.yml` には `test`
と `dev` 環境の実用的なデフォルトが収められています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために
`factories.yml` のコンフィギュレーションを次のように更新するとよいでしょう:
+symfony 1.3 では新しいメーラーファクトリが用意されています。アプリケーションが作られるとき、`factories.yml` には `test`
と `dev` 環境の実用的なデフォルトが収められています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために
`factories.yml` のコンフィギュレーションを次のように更新するとよいでしょう:
[yml]
mailer:
Modified: doc/branches/1.4/tutorial/ja/whats-new.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-25 02:35:07 UTC
(rev 28775)
+++ doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-25 07:44:47 UTC
(rev 28776)
@@ -11,7 +11,7 @@
メーラー
--------
-symfony 1.3/1.4 では SwiftMailer 4.1 をベースにする標準メーラーが新たに用意されました。
+symfony 1.3/1.4 では SwiftMailer 4.1 をベースとする標準メーラーが新たに用意されました。
メールの送信方法はシンプルでアクションから `composeAndSend()` メソッドを使うだけです:
@@ -51,7 +51,7 @@
### `sfWidgetFormInputText`
-`sfWidgetFormInput` クラスは抽象クラスになりました。テキスト入力フィールドは `sfWidgetFormInputText`
クラスで作られます。この変更によってフォームクラスのイントロスペクションはより簡単になりました。
+`sfWidgetFormInput` クラスは抽象クラスになりました。テキスト入力フィールドは `sfWidgetFormInputText`
クラスのなかで作られます。この変更によってフォームクラスのイントロスペクションはより簡単になりました。
### 国際化ウィジェット
@@ -136,13 +136,13 @@
>**NOTE**
>`setRequiredMessage()` と `setInvalidMessage()` メソッドは廃止予定なので、代わりに新しい
>`setDefaultMessage()` メソッドを呼び出します。
-symfony がエラーを表示するとき、使われるエラーメッセージは次のように決まります:
+symfony がエラーを表示するとき、使われるエラーメッセージは次のように決められます:
- * バリデータが作られるときに渡されるメッセージを探索されます (バリデータのコンストラクタの第2引数経由);
+ * バリデータが作られるときに渡されるメッセージが探索されます (バリデータのコンストラクタの第2引数経由);
- * 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージが探索されます;
+ * コンストラクタで定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージが探索されます;
- * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき)
バリデータ自身で定義される初期メッセージに戻ります。
+ * `setDefaultMessage()` メソッドで定義されていなければ (メッセージが `addMessage()`
メソッドで追加されているとき)、バリデータ自身で定義される初期メッセージに戻ります。
### 流れるようなインターフェイス
@@ -165,7 +165,7 @@
### `sfForm::useFields()`
-新しい `sfForm::useFields()`
メソッドは引数として提供されるフィールド以外、隠しフィールドではないすべてのフィールドをフォームから削除します。ときには不要なフィールドの割り当てを解除するよりもフォームで維持したいフィールドを明示的に指示するほうが簡単です。たとえば、新しいフィールドを基底フォームに追加するとき、これらのフィールドは明示的に追加されるまでフォームに自動表示されることはありません
(モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。
+新しい `sfForm::useFields()`
メソッドは引数として提供されるフィールド以外、隠しフィールドではないすべてのフィールドをフォームから削除します。ときには不要なフィールドの割り当てを解除するよりもフォームで維持したいフィールドを明示的に指示するほうが簡単です。たとえば新しいフィールドを基底フォームに追加するとき、これらのフィールドは明示的に追加されるまでフォームに自動表示されることはありません
(モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。
[php]
class ArticleForm extends BaseArticleForm
@@ -209,11 +209,11 @@
### `sfForm::doBind()`
-わかりやすくするために汚染されたパラメータのクリーニングは `->doBind()`
メソッドに隔離されました。このメソッドはパラメータとファイルのマージ済みの配列を `->bind()` から受け取ります。
+開発者にわかりやすくするために、汚染されたパラメータのクリーニングは `->doBind()`
メソッドに隔離されました。このメソッドはパラメータとファイルのマージ済みの配列を `->bind()` から受け取ります。
### `sfForm(Doctrine|Propel)::doUpdateObject()`
-扱いやすくするために Doctrine と Propel のフォームクラスに `->doUpdateObject()`
メソッドが追加されました。このメソッドは すでに `->processValues()` によって処理済みの値の配列を `->updateObject()`
から受け取ります。
+開発者に扱いやすくするために、Doctrine と Propel のフォームクラスに `->doUpdateObject()`
メソッドが追加されました。このメソッドは すでに `->processValues()` によって処理済みの値の配列を `->updateObject()`
から受け取ります。
### `sfForm::enableLocalCSRFProtection()` と
`sfForm::disableLocalCSRFProtection()`
@@ -235,22 +235,22 @@
オートローダ
--------------
-symfony のすべてのオートローダは大文字と小文字を区別しないようになりました。PHP が大文字と小文字を区別をしないので、symfony
もそれに合わせることにしたからです。
+symfony のすべてのオートローダは大文字と小文字を区別しなくなりました。PHP が大文字と小文字を区別をしないことに合わせることにしたからです。
### `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
-どのように動くのかを説明します:
まず最初に、すべてのテストはいつもどおりに実行されます。引き続きテストを実行すると、最後のテストで通らなかったものだけが実行されます。コードを修正して一部のテストが通れば、次回以降の実行から除外されます。再びすべてのテストが通れば、完全なテストスイートが実行され、徹底的に繰り返すことができます。
+どのように動くのかを説明します。まず最初に、すべてのテストはいつもどおりに実行されます。引き続きテストを実行すると、最後のテストで通らなかったものだけが実行されます。コードを修正して一部のテストが通れば、次回以降の実行から除外されます。再びすべてのテストが通れば、完全なテストスイートが実行され、徹底的に繰り返すことができます。
### 機能テスト
@@ -301,7 +301,7 @@
checkForm($browser->getArticleForm())->
end();
-複数のフォームがレスポンスに含まれる場合にどの DOM 部分をテストするのかをきめ細かく指定するために CSS
セレクタを提供するオプションが用意されています:
+複数のフォームがレスポンスに含まれる場合、どの DOM 部分をテストするのかをきめ細かく指定するために CSS
セレクタを提供するオプションが用意されています:
[php]
$browser->with('response')->begin()->
@@ -430,14 +430,14 @@
### `sfBaseTask::setConfiguration()`
-PHP から `sfBaseTask` を継承するタスクを呼び出すとき、`->run()` に `--application` と `--env`
オプションを渡す必要はもはやありません。その代わりに`->setConfiguration()`
を呼び出すだけで設定オブジェクトを直接セットすることができます。
+PHP から `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);
@@ -497,7 +497,7 @@
### オートローディング
-オートロードのあいだに例外が投げられるとき、symfony
はこれらの例外を捕まえエラーをユーザーに出力します。これによっていくつかの「真っ白な」ページの問題が解決します。
+オートロードのあいだに例外が投げられるとき、symfony
はこれらの例外を捕まえエラーをユーザーに出力します。この対応によっていくつかの「真っ白な」ページの問題が解決されます。
### Web デバッグツールバー
@@ -606,7 +606,7 @@
プラグイン
----------
-symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin`
以外のすべてのプラグインがデフォルトで有効になっていました:
+symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin`
以外のすべてのプラグインがデフォルトで有効にされていました:
[php]
class ProjectConfiguration extends sfProjectConfiguration
@@ -654,7 +654,7 @@
### `sf_file_link_format`
-symfony 1.3/1.4 は可能であればファイルパスをクリック可能なリンク (すなわちデバッグ例外のテンプレート)
にフォーマットします。`sf_file_link_format` がセットされている場合、この目的に使われ、そうでなければ symfony は PHP
コンフィギュレーションの `xdebug.file_link_format` の値を探します。
+symfony 1.3/1.4 は可能であればファイルパスをクリック可能なリンク (すなわちデバッグ例外のテンプレート)
の形式に整えます。`sf_file_link_format` がセットされている場合、この目的に使われ、そうでなければ symfony は PHP
コンフィギュレーションの `xdebug.file_link_format` の値を探します。
たとえばファイルを TextMate で開きたい場合、次のコードを `settings.yml` に追加します:
@@ -699,7 +699,7 @@
#### モデルテーブルを作る
-指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するとき、 Doctrine
はあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃したくなく単にテーブル群を再構築したいときに役立ちます。
+指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するとき、 Doctrine
はあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃せずに単にテーブル群を再構築する際に役立ちます。
$ php symfony doctrine:create-model-tables Model1 Model2 Model3
@@ -723,7 +723,7 @@
新しい `doctrine:build` タスクによって symfony や Doctrine
にビルドしてほしいものを明確に指定できます。このより柔軟性のある解決方法に合わせて廃止予定になった既存の多くのタスクを組み合わせることで得られる機能をこのタスクを複製します。
-`doctrine:build` の使いかたは次のとおりです:
+`doctrine:build` の使い方は次のとおりです:
$ php symfony doctrine:build --db --and-load
@@ -796,7 +796,7 @@
### DQL タスクをテーブル形式のデータとして出力する
-これまでは `doctrine:dql` コマンドを実行したときデータは YAML 形式で出力されるだけでした。新しく追加された `--table`
オプションによって MySQL のコマンドライン出力と似たテーブル形式でデータを出力できるようになりました。そのため、次のような表現が可能になりました。
+従来では `doctrine:dql` コマンドを実行したときデータは YAML 形式で出力されるだけでした。新しく追加された `--table`
オプションによって MySQL のコマンドライン出力と似たテーブル形式でデータを出力できるようになりました。そのため、次のような表現が可能になりました。
$ ./symfony doctrine:dql "FROM Article a" --table
>> doctrine executing dql query
@@ -891,7 +891,7 @@
###
`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` オプションをとります。
+`doctrine:generate-module`、`doctrine:generate-admin`、`doctrine:generate-admin-for-route`
タスクは生成モジュールにおけるアクション基底クラスのコンフィギュレーションの変更を可能にする `--actions-base-class`
オプションをとります。
### マジックメソッドの PHPDoc タグ
Modified: doc/branches/1.4/tutorial/ja/which-version.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-25 02:35:07 UTC
(rev 28775)
+++ doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-25 07:44:47 UTC
(rev 28776)
@@ -7,8 +7,8 @@
古い 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.3 がサポートされる期間 (2010年11月まで)
に廃止予定の機能を削除してコードをゆっくりアップデートしてから、長期サポートの恩恵を得るために最終的に symfony 1.4
に移行するための時間は十分にあります。
このドキュメントは廃止予定の機能を説明しないので、すべての例は両方のバージョンで等しく動きます。
--
You received this message because you are subscribed to the Google Groups
"symfony SVN" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-svn?hl=en.
