Author: masaki
Date: 2010-03-22 06:21:01 +0100 (Mon, 22 Mar 2010)
New Revision: 28658
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-21 23:56:36 UTC
(rev 28657)
+++ doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-22 05:21:01 UTC
(rev 28658)
@@ -36,7 +36,7 @@
* `sfTestFunctional` の次のメソッド: `isCached()`、 `isUriCached()`: これらのメソッドは 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`
にセットする必要があります。
@@ -129,7 +129,7 @@
* `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`: このオプションはもう必要ありません。
@@ -138,16 +138,16 @@
* `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`): `is_internal`
フラグはアクションがブラウザから呼び出されるのを防ぐために使われました。これは symfony 1.0
でメール送信を保護するために追加されました。このトリックがメールのサポートに必要なくなったので、このフラグは削除され symfony
コアではチェックされません。
タスク
------
次のタスクが 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 で削除されます:
@@ -174,7 +174,7 @@
`sfNamespacedParameterHolder::get()`、
`sfNamespacedParameterHolder::has()` と
`sfNamespacedParameterHolder::remove()` メソッドの配列表記 (`[]`) のサポートは廃止予定になり symfony
1.4 では利用できません (パフォーマンスの向上)。
-symfony CLI はグローバルな `--dry-run` オプションを受け取ることはありません。このオプションは symfony
の組み込みタスクによって使われていなかったからです。タスクの1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。
+symfony CLI はグローバルな `--dry-run` オプションを受け入れなくなりました。このオプションは symfony
の組み込みタスクによって使われていなかったからです。タスクの1つがこのオプションに依存する場合、これをタスククラスのローカルオプションとして追加できます。
1.0 のアドミンジェネレータの Propel テンプレートと 1.0 の CRUD は symfony 1.4 で削除されます
(`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`)。
Modified: doc/branches/1.4/tutorial/ja/upgrade.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-21 23:56:36 UTC
(rev 28657)
+++ doc/branches/1.4/tutorial/ja/upgrade.markdown 2010-03-22 05:21:01 UTC
(rev 28658)
@@ -19,7 +19,7 @@
このタスクは symfony 1.4 に切り替える前に変更する必要のあるすべてのファイルの一覧を表示します。
-このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするためのものであり、魔法の道具ではありません。「1.3
の廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。
+このタスクが多くの誤判断をしてしまう可能性のある見せかけの正規表現であることにご注意ください。また、このタスクはすべてを検出できるものではなく、起こりうる問題を特定するのを手助けするためのものであり、魔法の道具ではありません。「1.3
での廃止予定および削除される機能」のチュートリアルも注意深く読む必要があります。
>**NOTE**
>`sfCompat10Plugin` と `sfProtoculousPlugin` は 1.4
>から削除されました。`config/ProjectConfiguration.class.php`
>などのプロジェクトの設定ファイルでこれらを明示的に無効にする場合、これらのファイルからこれらの記述をすべて削除しなければなりません。
@@ -76,9 +76,9 @@
`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 のオートローダは大文字と小文字を区別しません。
@@ -108,7 +108,7 @@
### 共通フィルタの削除
-`sfCommonFilter` は削除されデフォルトでは使われていません。このフィルタは自動的に JavaScript
とスタイルシートのタグをレスポンスのコンテンツに投入していました。レイアウトのなかで `include_stylesheets()` と
`include_javascripts()` ヘルパーを明示的に呼び出すことでこれらのアセットを手動でインクルードする必要があります:
+`sfCommonFilter` は削除されデフォルトでは使われていません。このフィルタは JavaScript
とスタイルシートのタグをレスポンスのコンテンツに自動投入していました。これらのアセットを手動でインクルードするにはレイアウトのなかで
`include_stylesheets()` と `include_javascripts()` ヘルパーを明示的に呼び出すことが必要です:
[php]
<?php include_javascripts() ?>
@@ -116,21 +116,21 @@
これはいくつかの理由から削除されました:
- * すでによりすぐれた、シンプルで、より柔軟な解決方法があります (`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` タスクによって自動的に行われます - これらは `<head>` タグをもたなければなりません;
ほかのレイアウト、もしくはレイアウトをもたないが JavaScript
ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。
+ * 以前と同じふるまいを保つには `include_stylesheets()` と `include_javascripts()`
呼び出しをレイアウトに追加する必要があります (この作業はアプリケーションの `templates/` ディレクトリに収められている HTML レイアウト用の
`project:upgrade1.3` タスクによって自動的に行われます - これらは `<head>` タグをもたなければなりません;
ほかのレイアウト、もしくはレイアウトをもたないが JavaScript
ファイルかつ/もしくスタイルシートに依存するページを手動でアップグレードする必要があります)。
>**NOTE**
@@ -157,7 +157,7 @@
エスケーピング
---------------
-`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 との統合
-----------------
@@ -180,7 +180,7 @@
type: string(255)
>**NOTE**
->package オプションは Doctrine の機能で symfony プラグインのスキーマに使われます。package
機能はモデルのパッケージを作るために独立して使うことができることを意味しません。これは直接および symfony プラグインでのみ使わなければなりません。
+>package オプションは Doctrine の機能で symfony プラグインのスキーマに使われます。このことは package
機能がモデルのパッケージを作るために単独で使うことができることを意味しません。これは直接および symfony プラグインでのみ使わなければなりません。
### クエリのロギング
@@ -189,7 +189,7 @@
プラグイン
----------
-`ProjectConfiguration` クラスで有効にされるプラグインを管理するために `enableAllPluginsExcept()`
メソッドを使う場合、異なるプラットフォームのあいだの一貫性を保証するためにプラグインを名前順でソートするように警告されます。
+`ProjectConfiguration` クラスで有効にされているプラグインを管理するために `enableAllPluginsExcept()`
メソッドを使う場合、異なるプラットフォームのあいだの一貫性を保証するためにプラグインを名前順でソートするように警告されます。
ウィジェット
------------
@@ -199,7 +199,7 @@
メーラー
--------
-symfony 1.3 は新しいメーラーファクトリを備えています。アプリケーションを作るとき、`factories.yml` は `test` と
`dev` 環境の実用的なデフォルトを備えています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために `factories.yml`
を次のコンフィギュレーションに更新するとよいでしょう:
+symfony 1.3 には新しいメーラーファクトリが用意されています。アプリケーションを作るとき、`factories.yml` は `test` と
`dev` 環境の実用的なデフォルトを備えています。しかし既存のプロジェクトをアップグレードする場合、これらの環境のために `factories.yml`
を次のコンフィギュレーションに更新するとよいでしょう:
[yml]
mailer:
@@ -218,14 +218,14 @@
delivery_address: [email protected]
>**CAUTION**
->プロジェクトが古いバージョンの Swiftmailer を使っている場合、それを削除しなければなりません。
+>プロジェクトが古いバージョンの Swiftmailer を使っている場合はそれを削除しなければなりません。
YAML
----
-sfYAML は 1.2 の仕様とより互換性をもちます。設定ファイルで変更する必要のあるものは次のとおりです:
+sfYAML は 1.2 の仕様とより多くの互換性をもちます。設定ファイルで変更する必要のあるものは次のとおりです:
- * ブール値は文字列の `true` もしくは `false` でのみ表現されます。次のリストのなかの代替文字列を使っているのであれば、これらを
`true` もしくは `false` に置き換えなければなりません:
+ * ブール値は文字列の `true` もしくは `false` だけで表現されます。次のリストに入っている代替文字列を使っているのであれば、`true`
もしくは `false` に置き換えなければなりません:
* `on`, `y`, `yes`, `+`
* `off`, `n`, `no`, `-`
@@ -281,4 +281,4 @@
)));
$autoload->register();
-`project:upgrade` タスクはこの変更を行おうとしますが、`test/bootstrap/unit.php`
でローカルな変更をすることが不可能な場合があります。
+`project:upgrade` タスクはこの変更を加えようとしますが、`test/bootstrap/unit.php`
でローカルな変更をすることが不可能な場合があります。
Modified: doc/branches/1.4/tutorial/ja/whats-new.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-21 23:56:36 UTC
(rev 28657)
+++ doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-22 05:21:01 UTC
(rev 28658)
@@ -1,7 +1,7 @@
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 およびそれ以降のバージョンと互換性があることにご注意ください。
@@ -43,7 +43,7 @@
### 標準ラベル
-ラベルがフィールド名で自動生成される場合、接尾辞の `_id` は削除されます:
+ラベルがフィールド名から自動生成される場合、接尾辞の `_id` はつかなくなりました:
* `first_name` => First name (以前と同じ)
* `author_id` => Author (以前は "Author id" )
@@ -87,7 +87,7 @@
`sfValidatorRegex` に新しい `must_match` オプションが用意されました。このオプションが `false`
にセットされている場合、正規表現は渡すバリデータにマッチしません。
-`sfValidatorRegex` の `pattern` オプションは呼び出されるときに正規表現を返す `sfCallable`
のインスタンスにしなければならなくなりました。
+`sfValidatorRegex` の `pattern` オプションの値は呼び出されるときに正規表現を返す `sfCallable`
のインスタンスにしなければならなくなりました。
### `sfValidatorUrl`
@@ -157,7 +157,7 @@
### `sfValidatorFile`
-`php.ini` で `file_uploads` が無効な場合 `sfValidatorFile` のインスタンスを作るときに例外が投げられます。
+`php.ini` で `file_uploads` が無効な場合 `sfValidatorFile` のインスタンスを作る際に例外が投げられます。
フォーム
--------
@@ -183,7 +183,7 @@
### `sfForm::renderHiddenFields()`
-`->renderHiddenFields()`
メソッドは組み込みフォームからの隠しフィールドをレンダリングします。再帰処理を無効にする引数が追加されました。これはフォーマッタを使って組み込みフォームをレンダリングする場合に便利です。
+`->renderHiddenFields()`
メソッドは組み込みフォームからの隠しフィールドをレンダリングします。フォーマッタを使って組み込みフォームをレンダリングする場合に役立つ再帰処理を無効にする引数が追加されました。
[php]
// 組み込みフォームからのフィールドを含めて、すべての隠しフィールドをレンダリングする
@@ -204,15 +204,15 @@
### `BaseForm`
-Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使うことのできる `BaseForm` クラスが symfony
1.3/1.4 のすべての新しいプロジェクトに入ります。`sfDoctrinePlugin` と `sfPropelPlugin`
によって生成されるフォームはこのクラスを自動的に継承します。追加のフォームクラスを作るのであれば `sfForm` ではなく `BaseForm`
を継承させるべきです。
+Form コンポーネントを拡張するもしくはプロジェクト固有の機能を追加するために使うことのできる `BaseForm` クラスが symfony
1.3/1.4 のすべての新しいプロジェクトに入ります。`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()`
@@ -245,17 +245,17 @@
### テストのスピードアップ
-大規模なテストスイートの場合、特にテストが通らない場合など変更するたびにすべてのテストを実行するのにとても時間がかかる可能性があります。なぜならテストを修正するたびに、何も壊していないことを確認するためにテストスイート全体を再度実行することになるからです。しかし、テストが修正されないかぎり、すべてのテストを再実行する必要はありません。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
形式の代わりに、人間が理解できる例外の説明をテキスト形式で出力するようになり、より簡単にデバッグできるようになりました。
-レスポンスの内容全体に対して正規表現で検索できる新しい `matches()` メソッドが `sfTesterResponse` に用意されました。これは
`checkElement()` が使えない XML 形式ではないレスポンスにとても役立ちます。力不足の `contains()`
メソッドの代わりとして使うこともできます:
+レスポンスの内容全体に対して正規表現で検索できる新しい `matches()` メソッドが `sfTesterResponse` に用意されました。これは
`checkElement()` が使えない XML 形式ではないレスポンスに重宝します。力不足の `contains()`
メソッドの代わりとして使うこともできます:
[php]
$browser->with('response')->begin()->
@@ -278,7 +278,7 @@
### 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);
@@ -292,7 +292,7 @@
checkForm('ArticleForm')->
end();
-もしくは、望むのであれば、フォームオブジェクトを渡すことができます:
+もしくは望むのであれば、フォームオブジェクトを渡すことができます:
[php]
@@ -309,7 +309,7 @@
### `sfTesterResponse::isValid()`
-レスポンスが整形式の XML であるかチェックするのにレスポンステスターの `->isValid()` メソッドを使うことができます:
+レスポンスが妥当な XML であるかチェックするのにレスポンステスターの `->isValid()` メソッドを使うことができます:
[php]
$browser->with('response')->begin()->
@@ -351,11 +351,11 @@
タスク
------
-symfony の CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI
は幅をデフォルトの78カラムに合わせようとします。
+symfony CLI はターミナルウィンドウの幅を検出することを試み、ラインのフォーマットを合わせようとします。検出できない場合 CLI
は幅をデフォルトの78カラムに合わせようとします。
### `sfTask::askAndValidate()`
-ユーザーに質問をして得られる入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新しく用意されました:
+ユーザーに質問をして得られる入力内容をバリデートする `sfTask::askAndValidate()` メソッドが新たに用意されました:
[php]
$answer = $this->askAndValidate('What is you email?', new
sfValidatorEmail());
@@ -373,7 +373,7 @@
### `project:deploy`
-`project:deply` タスクは少し改良されました。ファイルの転送状況をリアルタイムで表示するようになりました。ただし、`-t`
オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません。もちろんエラーの場合は除きます。エラーのときには、簡単に問題を認識できるように赤色を背景にエラー情報が出力されます。
+`project:deply` タスクは少し改良されました。ファイルの転送状況をリアルタイムで表示するようになりました。ただし、`-t`
オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません。もちろんエラーの場合は除きます。エラーのときには、問題を認識しやすくするために赤色を背景にエラー情報が出力されます。
### `generate:project`
@@ -389,12 +389,12 @@
$ php /path/to/symfony generate:project foo --orm=none
-新しい `--installer` オプションのおかげで新たに生成されるプロジェクトをかなりカスタマイズできる PHP
スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドで使うことができます。次のようなより便利なメソッドがあります:
+新しい `--installer` オプションのおかげで新たに生成されるプロジェクトをかなりカスタマイズできる PHP
スクリプトを指定することができます。スクリプトはタスクで実行され、タスクのメソッドで使うことができます。次のようなもっと便利なメソッドがあります:
`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` タグに使う値を指定します。
@@ -402,7 +402,7 @@
### `sfFileSystem::execute()`
-`sfFileSystem::sh()` メソッドはより強力な機能をもつ `sfFileSystem::execute()`
メソッドに置き換わります。このメソッドは `stdout` と `stderr`
出力のリアルタイム処理のコールバックをとります。また両方の出力を配列として返すこともできます。使い方の例は `sfProjectDeployTask`
クラスで見つけることができます。
+`sfFileSystem::sh()` メソッドはより強力な機能をもつ `sfFileSystem::execute()`
メソッドに置き換わりました。このメソッドは `stdout` と `stderr`
出力のリアルタイム処理のコールバックをとります。また両方の出力を配列として返すこともできます。使い方の例は `sfProjectDeployTask`
クラスで見つけることができます。
### `task.test.filter_test_files`
@@ -447,7 +447,7 @@
### `project:disable` と `project:enable`
-`project:disable` と `project:enable`タスクを使うことで、環境全体を無効、または有効にできるようになりました:
+`project:disable` と `project:enable` タスクを使うことで、環境全体を無効、または有効にできるようになりました:
$ php symfony project:disable prod
$ php symfony project:enable prod
@@ -587,7 +587,7 @@
### カラー出力
-symfony の CLI を使うとき、symfony
はあなたが利用しているコンソールがカラー出力をサポートしているかどうかを推定しようとします。しかし、symfony は推定を間違える場合があります;
たとえば、Cygwin を使っているときです (Windows プラットフォームではカラー出力はつねにオフだからです)。
+symfony の CLI を使うとき、symfony
はご利用のコンソールがカラー出力をサポートしているかどうかを推定しようとします。しかし、symfony は推定を間違える場合があります;
たとえば、Cygwin を使っているときです (Windows プラットフォームではカラー出力はつねにオフだからです)。
symfony 1.3/1.4 では、グローバルオプションの `--color` を渡すことでカラー出力を強制できるようになりました。
@@ -704,7 +704,7 @@
#### モデルファイルを削除する
-YAML
スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児となったモデル、フォームそしてフィルタクラスが出てきます。`doctrine:delete-model-files`
タスクを使うことで、モデルに関連する生成ファイルを手作業で削除できるようになりました。
+YAML
スキーマファイルのなかでモデルや名前を変更したり、使われなくなったモデルを削除することがよくあるでしょう。このような作業を行うと、孤児になったモデル、フォームそしてフィルタクラスが出てきます。`doctrine:delete-model-files`
タスクを使うことで、モデルに関連する生成ファイルを手作業で削除できるようになりました。
$ php symfony doctrine:delete-model-files ModelName
@@ -712,7 +712,7 @@
#### モデルファイルをきれいにする
-上記のプロセスを`doctrine:clean-model-files` タスクで自動化することで、どのモデルがディスクに存在するが YAML
スキーマファイルに存在しないかを見つけることができます。
+上記のプロセスを`doctrine:clean-model-files` タスクで自動化することで、どのモデルがディスクに存在するが YAML
スキーマファイルには存在しないかを見つけることができます。
$ php symfony doctrine:clean-model-files
@@ -722,7 +722,7 @@
新しい `doctrine:build` タスクによって symfony や Doctrine
にビルドしてほしいものを明確に指定できます。このより柔軟性のある解決方法に合わせて廃止予定になった既存の多くのタスクを組み合わせることで得られる機能をこのタスクを複製します。
-`doctrine:build` の使い方は次のとおりです:
+`doctrine:build` の使いかたは次のとおりです:
$ php symfony doctrine:build --db --and-load
@@ -795,7 +795,7 @@
### DQL タスクをテーブル形式のデータとして出力する
-これまでは `doctrine:dql` コマンドを実行するとデータは YAML 形式で出力されるだけでした。新しく追加された `--table`
オプションによって MySQL のコマンドライン出力と似たテーブル形式でデータを出力できるようになりました。そのため、次のような表現が可能になりました。
+これまでは `doctrine:dql` コマンドを実行したときデータは YAML 形式で出力されるだけでした。新しく追加された `--table`
オプションによって MySQL のコマンドライン出力と似たテーブル形式でデータを出力できるようになりました。そのため、次のような表現が可能になりました。
$ ./symfony doctrine:dql "FROM Article a" --table
>> doctrine executing dql query
@@ -816,7 +816,7 @@
### 機能テストでクエリをデバッグする
-`sfTesterDoctrine` クラスに `->debug()`
メソッドが用意されました。このメソッドは現在のコンテクストで実行されたクエリの情報を出力します。
+`sfTesterDoctrine` クラスに `->debug()`
メソッドが用意されました。このメソッドは現在のコンテキストで実行されたクエリの情報を出力します。
[php]
$browser->
@@ -914,11 +914,11 @@
### `sfWebDebugPanel::setStatus()`
-ウェブデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO`
よりも優先順位が高いメッセージがロギングされている場合、log パネルのタイトルの背景色は変わります。
+ウェブデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を与えるステータスを指定できるようになりました。たとえば、`sfLogger::INFO`
よりも優先順位が高いメッセージがロギングされている場合、log パネルのタイトルの背景色は変わります。
### `sfWebDebugPanel` リクエストパラメータ
-`sfWebDebugPanel` パラメータを URL
につけ足すことでページロードで開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば config
パネルを開くように ウェブデバッグツールバーはレンダリングされます。
+`sfWebDebugPanel` パラメータを URL
につけ足すことでページをロードするときに開くパネルを指定できるようになりました。たとえば、`?sfWebDebugPanel=config` を追加すれば
config パネルを開くようにウェブデバッグツールバーはレンダリングされます。
パネルはウェブデバッグツールバーの `request_parameters` オプションにアクセスすることでリクエストパラメータをインスペクトします:
@@ -954,7 +954,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-21 23:56:36 UTC
(rev 28657)
+++ doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-22 05:21:01 UTC
(rev 28658)
@@ -1,11 +1,11 @@
どちらのバージョンを選べばよいのか？
==================================
-symfony 1.3 と symfony 1.4
のドキュメントはまったく同じものです。2つの異なるバージョンに対してドキュメントが1つしかない状況はめったにないことなので、このドキュメントでは2つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をどのようにすればよいのかを説明します。
+symfony 1.3 と symfony 1.4
のドキュメントの内容はまったく同じです。2つの異なるバージョンに対してドキュメントが1つしかない状況はめったにないことなので、このドキュメントでは2つのバージョンの主な違いが何であり、あなたのプロジェクトのために最善の選択をどのようにすればよいのかを説明します。
symfony 1.3 と symfony 1.4 は両方とも同じ時期 (2009年末)
にリリースされ、実際のところ、これらは両方とも**まったく同じ機能一式**を備えています。2つのバージョンの唯一の違いは symfony
の古いバージョンとの後方互換性のサポートです。
-symfony 1.3 は古い symfony のバージョン (1.0、1.1 もしくは 1.2)
を使うレガシープロジェクトをアップグレードする場合に選ぶリリースです。これは廃止予定であるがまだ利用可能な後方互換性レイヤーとすべての機能を備えています。このことはアップグレードが楽でシンプルであり、そして安全でもあることを意味します。
+古い 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月まで)。
--
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.
