Author: masaki
Date: 2010-03-10 00:50:34 +0100 (Wed, 10 Mar 2010)
New Revision: 28445
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] brushed up the update tutorials
Modified: doc/branches/1.4/tutorial/ja/deprecated.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-09 23:49:37 UTC
(rev 28444)
+++ doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-09 23:50:34 UTC
(rev 28445)
@@ -8,7 +8,7 @@
次のコアプラグインは symfony 1.3 で廃止予定になり symfony 1.4 で削除されます:
- * `sfCompat10Plugin`:
このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります (1.0
のアドミンジェネレータとフォームシステム)。これらのなかには
`lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin` に設置される1.0
アドミンジェネレータのデフォルトテーマも含まれています。
+ * `sfCompat10Plugin`:
このプラグインが廃止予定になることで、動くためにこのプラグインに依存するほかのすべての要素も廃止予定になります
(1.0のアドミンジェネレータとフォームシステム)。これらのなかには
`lib/plugins/sfPropelPlugin/data/generator/sfPropelAdmin`
に設置される1.0アドミンジェネレータのデフォルトテーマも含まれています。
* `sfProtoculousPlugin`: このプラグインによって提供されるヘルパーは控えめな JavaScript
をサポートしないので、今後は使うべきではありません。
@@ -43,7 +43,7 @@
* `sfApplicationConfiguration::loadPluginConfig()`: 代わりに
`initializePlugins()` を使います。
- * `sfLoader::getHelperDirs()` と `sfLoader::loadHelpers()`:
`sfApplicationConfiguration` オブジェクトから同じメソッドを使ってください。`sfLoader`
クラスのすべてのメソッドは廃止予定になったので、`sfLoader` は symfony 1.4 で削除されます。
+ * `sfLoader::getHelperDirs()` と `sfLoader::loadHelpers()`:
`sfApplicationConfiguration` オブジェクトから同じメソッドを使ってください。`sfLoader`
クラスのすべてのメソッドは廃止予定なので、`sfLoader` は symfony 1.4 で削除されます。
* `sfController::sendEmail()`: 代わりに symfony 1.3 の新しいメーラー機能を使います。
@@ -119,13 +119,13 @@
次の設定 (`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回よりも多くの転送が必要な場合、問題の認識とパフォーマンスの両方で問題があります。
- * `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`: `strip_comments` は PHP 5.0.x
のトークナイザが原因でバグのあるコメント除外機能を無効にできるように導入されました。Tokenizer エクステンションが PHP
によってコンパイルされていなかったとき、メモリの大量消費を避けるためにも使われていました。最初の問題は PHP
の最小バージョンが5.2になり無関係になっており2番目の問題はコメント除外機能をシミュレートした正規表現を削除することですでに修正されています。
* `lazy_routes_deserialize`: このオプションはもう必要ありません。
@@ -136,7 +136,7 @@
* `validation_error_prefix`、`validation_error_suffix`、
`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`): `is_internal`
フラグはブラウザからアクションが呼び出されるのを防ぐために使われました。これは symfony 1.0
でメール送信を保護するために追加されました。メールのサポートにこのトリックが必要なくなったので、このフラグは削除され symfony
コアではチェックされません。
タスク
------
@@ -166,7 +166,8 @@
次のふるまいは symfony 1.3 で廃止予定で、symfony 1.4 で削除されます:
* `sfParameterHolder::get()`、`sfParameterHolder::has()`、
- `sfParameterHolder::remove()`、`sfNamespacedParameterHolder::get()`、
+ `sfParameterHolder::remove()`、
+ `sfNamespacedParameterHolder::get()`、
`sfNamespacedParameterHolder::has()` と
`sfNamespacedParameterHolder::remove()` メソッドの配列表記 (`[]`) のサポートは廃止予定になり symfony
1.4 では利用できません (パフォーマンスの向上)。
symfony CLI はグローバルな `--dry-run` オプションを受け取ることはありません。このオプションは symfony
の組み込みタスクによって使われていなかったからです。タスクの 1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。
@@ -181,4 +182,4 @@
`sfDoctrinePlugin_doctrine_lib_path` 設定は、以前 Doctrine のカスタム lib
ディレクトリを指定するのに使われていましたが、1.3で廃止予定になり1.4で削除されます。代わりに `sf_doctrine_dir` 設定を使ってください。
-symfony のすべての `Base*` クラスの可視性は `abstract` ではありません。
+symfony のすべての `Base*` クラスは抽象クラスではありません。
Modified: doc/branches/1.4/tutorial/ja/upgrade.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-09 23:49:37 UTC
(rev 28444)
+++ doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-09 23:50:34 UTC
(rev 28445)
@@ -6,7 +6,7 @@
symfony 1.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 にアップグレードする
--------------------------------
@@ -19,7 +19,7 @@
このタスクは symfony 1.4 に切り替える前に変更する必要のあるすべてのファイルの一覧を表示します。
-このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするものであり、魔法の道具ではありません。「1.3の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。
+このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするためのものであり、魔法の道具ではありません。「1.3の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。
>**NOTE**
>`sfCompat10Plugin` と `sfProtoculousPlugin`
>は1.4から削除されました。`config/ProjectConfiguration.class.php`
>などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。
@@ -33,15 +33,15 @@
* 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
もしくは最新のバージョンにアップグレードするたびに、このタスクを起動させなければなりません。
+ このタスクは副作用なしで複数回実行できます。新しい symfony 1.3 beta/RC
もしくは最新のバージョンにアップグレードするたびに、このタスクを起動させなければなりません。
* 下記で説明される変更のために、モデルとフォームをリビルドする必要があります:
@@ -60,10 +60,10 @@
廃止予定の機能
--------------
-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` 設定ファイルに追加します:
@@ -90,7 +90,7 @@
`lazy_routes_deserialize` オプションはもはや必要ないので削除されました。
-symfony 1.3
に関しては、ルーティングキャッシュが無効になりました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。symfony
1.2 のデフォルトコンフィギュレーションに戻すために `factories.yml` に追加する内容は次のとおりです:
+symfony 1.3
に関して、ルーティングキャッシュが無効になりました。これはパフォーマンスの観点からたいていのプロジェクトにはベストなオプションです。ですので、ルーティングキャッシュをカスタマイズしなければ、これはすべてのアプリケーションで自動的に無効になります。1.3にアップグレードした後で、プロジェクトの動作が遅くなる場合、役に立っているのか確認するためにルーティングキャッシュを追加するとよいでしょう。symfony
1.2 のデフォルトコンフィギュレーションに戻すには次の内容を `factories.yml` に追加します:
[yml]
routing:
@@ -134,7 +134,7 @@
>**NOTE**
->`sfCommonFilter` クラスはまだ symfony 1.3 に搭載されているので、必要であれば `filters.yml`
のなかでこれを使うことができます。
+>`sfCommonFilter` クラスはまだ symfony 1.3 に搭載されているので、必要があれば `filters.yml`
のなかでこれを使うことができます。
タスク
@@ -155,9 +155,9 @@
`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 との統合
-----------------
@@ -168,11 +168,11 @@
### アドミンジェネレータの削除機能
-アドミンジェネレータバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに
`delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを起動させるためです。
+アドミンジェネレータバッチの削除機能はレコードをすべて削除する単独の DQL クエリを発行する代わりにレコードをフェッチしてそれぞれの個別のレコードに
`delete()` メソッドを発行するように変更されました。それぞれの個別のレコードを削除するためのイベントを立ち上げるためです。
### Doctrine プラグインスキーマをオーバーライドする
-ローカルスキーマで同じモデルを定義することでプラグインの YAML スキーマに含まれるモデルをオーバーライドできます。たとえば、`email` カラムを
`sfDoctrineGuardPlugin` の `sfGuardUser` モデルに追加するには、次のコードを
`config/doctrine/schema.yml` に追加します:
+ローカルスキーマで同じモデルを定義することでプラグインの YAML スキーマに含まれるモデルをオーバーライドできます。たとえば、
`sfDoctrineGuardPlugin` で `email` カラムを `sfGuardUser` モデルに追加するには、次のコードを
`config/doctrine/schema.yml` に追加します:
sfGuardUser:
columns:
@@ -184,7 +184,7 @@
### クエリのロギング
-Doctrine 統合ログクエリはロガーオブジェクトに直接アクセスする代わりに `sfEventDispatcher`
を使うことで機能します。加えて、これらのイベントの監視対象は接続もしくはクエリを実行するステートメントです。ロギングは新しい
`sfDoctrineConnectionProfiler` クラスによって行われ、このクラスは `sfDoctrineDatabase`
オブジェクトを通してアクセスできます。
+Doctrine 統合ログクエリはロガーオブジェクトに直接アクセスする代わりに `sfEventDispatcher`
を使うことで機能します。加えて、これらのイベントの監視対象は接続もしくはクエリを実行する命令文です。ロギングは新しい
`sfDoctrineConnectionProfiler` クラスによって行われ、このクラスは `sfDoctrineDatabase`
オブジェクトを通してアクセスできます。
プラグイン
----------
@@ -208,7 +208,7 @@
以前のコンフィギュレーションでは、メールは送信されません。もちろん、これらはまだロギングされ、`mailer` テスターは機能テストでまだ動きます。
-1つのアドレスですべてのメールを受信したいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境):
+1つのメールアドレスですべてのメールを受信したいのであれば `single_address` 配信戦略を使います (たとえば `dev` 環境):
[yml]
dev:
@@ -222,7 +222,7 @@
sfYAML は 1.2 の仕様とより互換性をもちます。設定ファイルで変更する必要のあるものは次のとおりです:
- * ブール値は文字列の `true` もしくは `false` でのみ表現されます。次のリストのなかの代替文字列を使っている場合、これらを `true`
もしくは `false` に置き換えなければなりません:
+ * ブール値は文字列の `true` もしくは `false` でのみ表現されます。次のリストのなかの代替文字列を使っているのであれば、これらを
`true` もしくは `false` に置き換えなければなりません:
* `on`, `y`, `yes`, `+`
* `off`, `n`, `no`, `-`
Modified: doc/branches/1.4/tutorial/ja/whats-new.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-09 23:49:37 UTC
(rev 28444)
+++ doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-09 23:50:34 UTC
(rev 28445)
@@ -76,8 +76,9 @@
`setFormFormatterName()`、 `setNameFormat()`、`setLabels()`、`setLabel()`、
`setHelps()`、`setHelp()`、`setParent()`
- * `sfWidgetFormSchemaDecorator`:
`addFormFormatter()`、`setFormFormatterName()`、`setNameFormat()`、
- `setLabels()`、`setHelps()`、`setHelp()`、`setParent()`、`setPositions()`
+ * `sfWidgetFormSchemaDecorator`:
`addFormFormatter()`、`setFormFormatterName()`、
+ `setNameFormat()`、`setLabels()`、`setHelps()`、`setHelp()`、`setParent()`、
+ `setPositions()`
バリデータ
------------
@@ -136,7 +137,7 @@
symfony がエラーを表示するとき、使われるエラーメッセージは次のように決定されます:
- * symfony はバリデータが作られたときに渡されたメッセージを探します (バリデータのコンストラクタの第2引数経由);
+ * symfony はバリデータが作られるときに渡されるメッセージを探します (バリデータのコンストラクタの第2引数経由);
* 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージを探します;
@@ -150,8 +151,9 @@
* `sfValidatorErrorSchema`: `addError()`、`addErrors()`
- * `sfValidatorBase`: `addMessage()`、`setMessage()`、`setMessages()`、
- `addOption()`、`setOption()`、`setOptions()`、`addRequiredOption()`
+ * `sfValidatorBase`: `addMessage()`、`setMessage()`、
+ `setMessages()`、`addOption()`、`setOption()`、
+ `setOptions()`、`addRequiredOption()`
### `sfValidatorFile`
@@ -162,7 +164,7 @@
### `sfForm::useFields()`
-新しい `sfForm::useFields()`
メソッドはフォームから引数として提供されるもの以外、隠しフィールドではないフィールドすべてを削除します。ときには不要なフィールドの割り当てを解除する代わりにフォームで維持したいフィールドを明示的に指示するのが簡単になります。たとえば、新しいフィールドを基底フォームに追加するとき、これらは明示的に追加されるまでフォームに自動表示されることはありません
(モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。
+新しい `sfForm::useFields()`
メソッドはフォームから引数として提供されるもの以外、隠しフィールドではないフィールドすべてを削除します。ときには不要なフィールドの割り当てを解除するよりもフォームで維持したいフィールドを明示的に指示するほうが簡単です。たとえば、新しいフィールドを基底フォームに追加するとき、これらは明示的に追加されるまでフォームに自動表示されることはありません
(モデルフォームで新しいカラムを関連テーブルに追加する場合を考えてください)。
[php]
class ArticleForm extends BaseArticleForm
@@ -194,10 +196,10 @@
新しい `sfFormSymfony` クラスはイベントディスパッチャを symfony フォームに導入します。`self::$dispatcher`
を通してフォームクラス内部のディスパッチャにアクセスできます。次のフォームイベントが symfony によって通知されます:
- * `form.post_configure`: このイベントはフォームが設定された後で通知される
- * `form.filter_values`:
このイベントは、マージされ汚染されたパラメータと、バインドする直前のファイルの配列をフィルタリングする
- * `form.validation_error`: フォームバリデーションが通らないときこのイベントが通知される
- * `form.method_not_found`: 身元不明のメソッドが呼び出されるときにこのイベントが通知される
+ * `form.post_configure`: このイベントはフォームが設定された後で通知されます。
+ * `form.filter_values`:
このイベントは、マージされ汚染されたパラメータと、バインドする直前のファイルの配列をフィルタリングします。
+ * `form.validation_error`: フォームバリデーションが通らないときこのイベントが通知されます。
+ * `form.method_not_found`: 身元不明のメソッドが呼び出されるときにこのイベントが通知されます。
### `BaseForm`
@@ -206,11 +208,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()`
@@ -243,7 +245,7 @@
### テストのスピードアップ
-大規模なテストスイートの場合、特にテストが通らない場合など変更するたびにすべてのテストを起動するのにとても時間がかかる可能性があります。なぜならテストを修正するたびに、何も壊していないことを確認するためにテストスイート全体を再度実行することになるからです。しかし、テストが修正されないかぎり、すべてのテストを再実行する必要はありません。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
@@ -251,9 +253,9 @@
### 機能テスト
-リクエストが例外を生成するとき、レスポンステスターの `debug()` メソッドは HTML
標準出力の代わりに、人間が読める例外のテキストの説明を出力するようになり、より簡単にデバッグできるようになりました。
+リクエストが例外を生成するとき、レスポンステスターの `debug()` メソッドは HTML
標準出力の代わりに、人間が読める例外の説明をテキスト形式で出力するようになり、より簡単にデバッグできるようになりました。
-`sfTesterResponse` にレスポンスの内容全体に対して正規表現で検索を行える新しい `matches()` メソッドが用意されました。これは
XML のようなものではなく `checkElement()` が使えないレスポンスにとても役立ちます。力不足の `contains()`
メソッドの代わりとして使うこともできます:
+レスポンスの内容全体に対して正規表現で検索を行える新しい `matches()` メソッドが `sfTesterResponse` に用意されました。これは
`checkElement()` が使えない XML のようなものではないレスポンスにとても役立ちます。力不足の `contains()`
メソッドの代わりとして使うこともできます:
[php]
$browser->with('response')->begin()->
@@ -270,20 +272,20 @@
### 簡単なデバッグ
-テストが通らなかったことをテストハーネスが報告するときにデバッグを簡単にするために、通らないものについて詳細な出力ができる `--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`
の lime コンストラクタの第2引数を省略できるということです:
[php]
$t = new lime_test(1);
### `sfTesterResponse::checkForm()`
-フォームのすべてのフィールドが正しくレンダリング処理されてレスポンスに含まれているかどうかをより簡単に確かめられるメソッドがレスポンステスターに入りました:
+フォームのすべてのフィールドが正しくレンダリングされてレスポンスに含まれているかどうかをより簡単に確かめられるメソッドがレスポンステスターに用意されました:
[php]
$browser->with('response')->begin()->
@@ -298,7 +300,7 @@
checkForm($browser->getArticleForm())->
end();
-レスポンスに複数のフォームが含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクタを提供するオプションがあります:
+複数のフォームがレスポンスに含まれる場合は、どの DOM 部分をテストするかをきめ細かく指定する CSS セレクタを提供するオプションがあります:
[php]
$browser->with('response')->begin()->
@@ -307,7 +309,7 @@
### `sfTesterResponse::isValid()`
-レスポンスが整形式の XML であるかをレスポンステスターの `->isValid()` メソッドでチェックできます:
+レスポンスが整形式の XML であるかチェックするのにレスポンステスターの `->isValid()` メソッドを使うことができます:
[php]
$browser->with('response')->begin()->
@@ -358,11 +360,11 @@
[php]
$anwser = $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
のコアテストスイートを実行できる `symfony:test` タスクが用意され、ほかのタスクと同じように使うことができます:
$ php symfony symfony:test
@@ -497,9 +499,9 @@
オートロードのあいだに例外が投げられるとき、symfony
はこれらを捕まえエラーをユーザーに出力します。これはいくつかの「真っ白な」ページの問題を解決します。
-### Web デバッグツールバー
+### ウェブデバッグツールバー
-可能であれば、開発環境の例外ページでも Web デバッグツールバーが表示されるようになりました。
+可能であれば、開発環境の例外ページでもウェブデバッグツールバーが表示されるようになりました。
Propel との統合
---------------
@@ -529,7 +531,7 @@
propel_behaviors:
timestampable: ~
-もしくは古い `schema.yml` 構文を使う場合、次のようになります:
+もしくは `schema.yml` の古い構文を使う場合、次のようになります:
propel:
article:
@@ -572,7 +574,7 @@
### `sfObjectRouteCollection` オプション
-新しい `default_params` オプションが `sfObjectRouteCollection`
に追加されました。これはそれぞれの生成ルートにデフォルトパラメータを登録することを可能にします:
+新しい `default_params` オプションが `sfObjectRouteCollection`
に追加されました。これはデフォルトパラメータをそれぞれの生成ルートに登録することを可能にします:
[yml]
forum_topic:
@@ -629,7 +631,7 @@
`plugin:install` タスクはインストールするプラグインを自動的に有効にします (そして `plugin:uninstall`
はプラグインを無効にします)。Subversion 経由でプラグインをインストールする場合、手動で有効にする必要があります。
-`sfProtoculousPlugin` もしくは `sfCompat10Plugin` のようなコアプラグインを使いたい場合、必要なのは対応する
`enablePlugins()` ステートメントを `ProjectConfiguration` クラスに追加することだけです。
+`sfProtoculousPlugin` もしくは `sfCompat10Plugin` のようなコアプラグインを使いたい場合、必要なのは対応する
`enablePlugins()` メソッドを `ProjectConfiguration` クラスに追加することだけです。
>**NOTE**
>1.2からプロジェクトをアップグレードする場合、古いふるまいはアクティブなままです。これはアップグレードタスクが
>`ProjectConfiguration` ファイルを変更しないからです。このふるまいの変更は symfony 1.3/1.4
>の新規プロジェクトのみです。
@@ -689,7 +691,7 @@
### フォームクラスの継承
-モデルクラスからフォームを生成するとき、モデルクラスは継承を含んでいます。生成された子クラスは継承を尊重し、同じ継承構造にしたがうフォームを生成します。
+モデルクラスからフォームを生成するとき、モデルクラスは継承を含んでいます。生成された子クラスは継承を尊重し、同じ継承構造に従うフォームを生成します。
### 新しいタスク
@@ -788,7 +790,7 @@
### `doctrine:migrate --dry-run`
-データベースが DDL ステートメントのロールバックをサポートする場合 (MySQL はサポートしません)、新しい `dry-run`
オプションを利用できます。
+データベースが DDL 文のロールバックをサポートする場合 (MySQL はサポートしません)、新しい `dry-run` オプションを利用できます。
$ php symfony doctrine:migrate --dry-run
@@ -807,9 +809,9 @@
+----+-----------+----------------+---------------------+---------------------+
(2 results)
-### クエリパラメータを `doctrine:dql` に渡す
+### `doctrine:dql` にクエリパラメータを渡す
-`doctrine:dql` タスクもクエリパラメータを引数として受け取れるよう強化されました:
+`doctrine:dql` タスクもクエリパラメータを引数にとれるよう強化されました:
$ php symfony doctrine:dql "FROM Article a WHERE name LIKE ?" John%
@@ -917,9 +919,9 @@
### `sfWebDebugPanel` リクエストパラメータ
-`sfWebDebugPanel` パラメータを URL
につけ加えることでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば
config パネルを開くように ウェブデバッグツールバーはレンダリングされます。
+`sfWebDebugPanel` パラメータを URL
につけ足すことでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config
パネルを開くように ウェブデバッグツールバーはレンダリングされます。
-パネルは Web デバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータをインスペクトします:
+パネルはウェブデバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータをインスペクトします:
[php]
$requestParameters = $this->webDebug->getOption('request_parameters');
@@ -929,14 +931,14 @@
### スロットの改善
-スロットが提供されない場合、`get_slot()` と `include_slot()`
ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための2番目のパラメータを受けとります:
+スロットが提供されない場合、`get_slot()` と `include_slot()`
ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための2番目のパラメータを受け取ります:
[php]
<?php echo get_slot('foo', 'bar') // もし `foo` スロットが定義されていなければ 'bar'
が出力される ?>
<?php include_slot('foo', 'bar') // もし `foo` スロットが定義されていなければ 'bar' が出力される
?>
-ページャー
-----------
+ページャ
+---------
`sfDoctrinePager` と `sfPropelPager` メソッドは `Iterator` と `Countable`
インターフェイスを実装するようになりました。
@@ -953,7 +955,7 @@
ビューキャッシュ
-----------------
-ビューキャッシュマネージャは `factories.yml`
でパラメータを受けとります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。
+ビューキャッシュマネージャは `factories.yml`
でパラメータを受け取ります。ビューのキャッシュキーの生成はクラスを簡単に拡張できるように異なる方法でリファクタリングされました。
`factories.yml` で2つのパラメータが利用できます:
Modified: doc/branches/1.4/tutorial/ja/which-version.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-09 23:49:37 UTC
(rev 28444)
+++ doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-09 23:50:34 UTC
(rev 28445)
@@ -7,8 +7,8 @@
symfony 1.3 は古い symfony のバージョン (1.0、1.1 もしくは 1.2)
を使うレガシープロジェクトをアップグレードする場合に選びたいリリースです。これは 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.
