Author: masaki
Date: 2010-03-18 08:16:27 +0100 (Thu, 18 Mar 2010)
New Revision: 28598
Modified:
doc/branches/1.4/tutorial/ja/deprecated.markdown
doc/branches/1.4/tutorial/ja/whats-new.markdown
doc/branches/1.4/tutorial/ja/which-version.markdown
Log:
[doc-ja][1.4] small fix
Modified: doc/branches/1.4/tutorial/ja/deprecated.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-17 23:11:52 UTC
(rev 28597)
+++ doc/branches/1.4/tutorial/ja/deprecated.markdown 2010-03-18 07:16:27 UTC
(rev 28598)
@@ -9,7 +9,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
をサポートしないので、今後は使うべきではありません。
@@ -22,7 +22,7 @@
* `sfToolkit::getTmpDir()`: このメソッド呼び出しはすべて `sys_get_temp_dir()` に置き換わります。
* `sfToolkit::removeArrayValueForPath()`、
- `sfToolkit::hasArrayValueForPath()`、と `getArrayValueForPathByRef()`
+ `sfToolkit::hasArrayValueForPath()` と `getArrayValueForPathByRef()`
* `sfValidatorBase::setInvalidMessage()`: 新しい
`sfValidatorBase::setDefaultMessage()` メソッド呼び出しに置き換わります。
@@ -114,7 +114,7 @@
* `sfCompat10Plugin` によって提供される 1.0 のフォームシステムに関連するすべてのヘルパー:
`DateForm`、`Form`、`ObjectAdmin`、`Object` と `Validation`
-`form_tag()` ヘルパーの所属は `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4
でも利用可能です。
+`form_tag()` ヘルパーの所属グループが `Form` ヘルパーグループから `Url` ヘルパーグループに移動したので、 symfony 1.4
でも利用可能です。
PHP のインクルードパスからヘルパーをロードする機能は 1.3
で廃止予定になり1.4で削除されます。ヘルパーはプロジェクト、アプリケーションもしくはモジュールの `lib/helper/`
ディレクトリのどれか1つに設置しなければなりません。
@@ -129,25 +129,25 @@
* `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`: このオプションはもう必要ありません。
次の設定は 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 で廃止予定です。
- * `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 で削除されます:
Modified: doc/branches/1.4/tutorial/ja/whats-new.markdown
===================================================================
--- doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-17 23:11:52 UTC
(rev 28597)
+++ doc/branches/1.4/tutorial/ja/whats-new.markdown 2010-03-18 07:16:27 UTC
(rev 28598)
@@ -13,7 +13,7 @@
symfony 1.3/1.4 では SwiftMailer 4.1 にもとづく新しい標準メーラーが用意されました。
-メール送信にはシンプルでアクションから `composeAndSend()` メソッドを使うだけです:
+メールを送信するのはシンプルでアクションから `composeAndSend()` メソッドを使うだけです:
[php]
$this->getMailer()->composeAndSend('[email protected]', '[email protected]',
'Subject', 'Body');
@@ -41,7 +41,7 @@
ウィジット
---------
-### 標準のラベル
+### 標準ラベル
ラベルがフィールド名で自動生成される場合、接尾辞の `_id` は削除されます:
@@ -139,9 +139,9 @@
* symfony はバリデータが作られるときに渡されるメッセージを探します (バリデータのコンストラクタの第2引数経由);
- * 定義されていなければ、`setDefaultMessage()` メソッドで定義される初期メッセージを探します;
+ * 定義されていなければ、`setDefaultMessage()` メソッドで定義されている初期メッセージを探します;
- * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき)
バリデータ自身で定義される初期メッセージへ戻ります。
+ * もし、定義されていなければ、(メッセージが `addMessage()` メソッドで追加されているとき)
バリデータ自身で定義されている初期メッセージへ戻ります。
### 流れるようなインターフェイス
@@ -199,7 +199,7 @@
* `form.post_configure`: このイベントはフォームが設定された後で通知されます。
* `form.filter_values`:
このイベントは、マージされ汚染されたパラメータと、バインドする直前のファイルの配列をフィルタリングします。
* `form.validation_error`: フォームバリデーションが通らないときこのイベントが通知されます。
- * `form.method_not_found`: 身元不明のメソッドが呼び出されるときにこのイベントが通知されます。
+ * `form.method_not_found`: 見つからないメソッドが呼び出されるときにこのイベントが通知されます。
### `BaseForm`
@@ -212,7 +212,7 @@
### `sfForm(Doctrine|Propel)::doUpdateObject()`
-Doctrine と Propel のフォームクラスに開発者が扱いやすい `->doUpdateObject()` メソッドが加えられました。このメソッドは
すでに `->processValues()` によって処理された `->updateObject()` から値の配列を受け取ります。
+Doctrine と Propel のフォームクラスに開発者が扱いやすい `->doUpdateObject()` メソッドが追加されました。このメソッドは
すでに `->processValues()` によって処理された `->updateObject()` から値の配列を受け取ります。
### `sfForm::enableLocalCSRFProtection()` と
`sfForm::disableLocalCSRFProtection()`
@@ -229,7 +229,7 @@
`sfForm` メソッドは次のような流れるインターフェイスを実装するようになりました:
`addCSRFProtection()`、`setValidators()`、`setValidator()`、
`setValidatorSchema()`、`setWidgets()`、`setWidget()`、
-`setWidgetSchema()`、`setOption()`、`setDefault()`、そして `setDefaults()`
+`setWidgetSchema()`、`setOption()`、`setDefault()` そして `setDefaults()`
オートローダ
--------------
@@ -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
標準出力の代わりに、人間が読める例外の説明をテキスト形式で出力するようになり、より簡単にデバッグできるようになりました。
+リクエストが例外を生成するとき、レスポンステスターの `debug()` メソッドは標準出力の HTML
形式の代わりに、人間が理解できる例外の説明をテキスト形式で出力するようになり、より簡単にデバッグできるようになりました。
-レスポンスの内容全体に対して正規表現で検索できる新しい `matches()` メソッドが `sfTesterResponse` に用意されました。これは
`checkElement()` が使えない XML のようなものではないレスポンスにとても役立ちます。力不足の `contains()`
メソッドの代わりとして使うこともできます:
+レスポンスの内容全体に対して正規表現で検索できる新しい `matches()` メソッドが `sfTesterResponse` に用意されました。これは
`checkElement()` が使えない XML 形式ではないレスポンスにとても役立ちます。力不足の `contains()`
メソッドの代わりとして使うこともできます:
[php]
$browser->with('response')->begin()->
@@ -340,7 +340,7 @@
### 改良された `->click()`
-`->click()` メソッドに CSS セレクタを渡すことが可能で、セマンティックにしたい要素をターゲットにするのがはるかに楽になりました。
+`->click()` メソッドに CSS セレクタを渡すことが可能になり、セマンティックにしたい要素をターゲットにするのがとても簡単になりました。
[php]
$browser
@@ -373,11 +373,11 @@
### `project:deploy`
-`project:deply` タスクは少し改良されました。ファイルの転送状況をリアルタイムで表示するようになりました。ただし、`-t`
オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません、もちろんエラーの場合は除きます。エラーのときには、簡単に問題を認識できるように赤色を背景にエラー情報が出力されます。
+`project:deply` タスクは少し改良されました。ファイルの転送状況をリアルタイムで表示するようになりました。ただし、`-t`
オプションが渡されたときだけです。もしオプションが指定されていなければタスクは何も表示しません。もちろんエラーの場合は除きます。エラーのときには、簡単に問題を認識できるように赤色を背景にエラー情報が出力されます。
### `generate:project`
-symfony 1.3/1.4 では、`generate:project` タスクを実行するとき、初期設定では ORM は Doctrine になります:
+symfony 1.3/1.4 で `generate:project` タスクを実行するとき、初期設定では ORM は Doctrine になります:
$ php /path/to/symfony generate:project foo
@@ -385,7 +385,7 @@
$ 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
@@ -471,7 +471,7 @@
この出力はこのタスクオブジェクトの XML 表現を返す新しい `sfTask::asXml()` メソッドにもとづいています。
-たいていの場合において XML 出力は IDE のようなサードパーティにとても役立つでしょう。
+たいていの場合において XML 出力は IDE のようなサードパーティに重宝するでしょう。
### `project:optimize`
@@ -485,7 +485,7 @@
### タスクからメールを送信する
-`getMailer()` メソッドを使うことでタスクからメールを簡単に送信することができるようになりました。
+`getMailer()` メソッドを使うことでタスクからメールを簡単に送信できるようになりました。
### タスクでルーティングを使う
@@ -587,7 +587,7 @@
### カラー出力
-symfony の CLI を使うとき、symfony
はあなたが利用しているコンソールがカラー出力をサポートしているかどうかを推測しようとします。しかし、symfony は推測を間違える場合があります;
たとえば、Cygwin を使っているときです (Windows プラットフォームではカラー出力はつねにオフだからです)。
+symfony の CLI を使うとき、symfony
はあなたが利用しているコンソールがカラー出力をサポートしているかどうかを推定しようとします。しかし、symfony は推定を間違える場合があります;
たとえば、Cygwin を使っているときです (Windows プラットフォームではカラー出力はつねにオフだからです)。
symfony 1.3/1.4 では、グローバルオプションの `--color` を渡すことでカラー出力を強制できるようになりました。
@@ -596,7 +596,7 @@
### データの更新
-国際化オペレーションに使われるすべてのデータは `ICU` プロジェクトから更新されました。symfony
には約330個のロケールファイルが付属しており、symfony 1.2
と比べると約70個増えています。ですのでたとえば、言語リストの10番目の項目をチェックするテストケースが通らない可能性があることにご注意をお願いします。
+国際化オペレーションに使われているすべてのデータは `ICU` プロジェクトから更新されました。symfony
には約330個のロケールファイルが付属しており、symfony 1.2
と比べると約70個増えています。ですので、たとえば言語リストの10番目の項目をチェックするテストケースが通らない可能性があることにご注意ください。
### ユーザーロケールを基準にソートする
@@ -605,7 +605,7 @@
プラグイン
----------
-symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin`
以外のすべてのプラグインはデフォルトで有効になっていました:
+symfony 1.3/1.4 以前では、`sfDoctrinePlugin` と `sfCompat10Plugin`
以外のすべてのプラグインがデフォルトで有効になっていました:
[php]
class ProjectConfiguration extends sfProjectConfiguration
@@ -617,7 +617,7 @@
}
}
-symfony 1.3/1.4 では、新しく作られたプロジェクトでプラグインを使うには `ProjectConfiguration`
クラスで明示的に有効にしなければなりません:
+symfony 1.3/1.4 では、新たに作られたプロジェクトでプラグインを使うには `ProjectConfiguration`
クラスで明示的に有効にしなければなりません:
[php]
class ProjectConfiguration extends sfProjectConfiguration
@@ -698,7 +698,7 @@
#### モデルテーブルを作る
-指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するときあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃したくなく単にテーブル群を再構築したいときに役立ちます。
+指定モデルの配列のためにテーブルを個別に作ることができるようになりました。テーブルを削除するとき Doctrine
はあなたに代わってテーブルを再作成してくれます。既存のプロジェクト/データベースで新しいモデルを開発するとき、データベース全体を一掃したくなく単にテーブル群を再構築したいときに役立ちます。
$ php symfony doctrine:create-model-tables Model1 Model2 Model3
@@ -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
@@ -824,7 +824,7 @@
with('doctrine')->debug()
;
-メソッドに数値を渡すことで直近の実行されたクエリの履歴を見ることができる、もしくは文字列を渡すことで文字列の一部にマッチするものや正規表現にマッチするクエリだけを表示することができます。
+メソッドに数値を渡すことで直近の実行されたクエリの履歴を見ることができる、もしくは文字列を渡すことで文字列の一部にマッチするクエリや正規表現にマッチするクエリだけを表示することができます。
[php]
$browser->
@@ -914,7 +914,7 @@
### `sfWebDebugPanel::setStatus()`
-ウェブデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO`
よりも優先順位が高いメッセージがロギングされる場合、log パネルのタイトルの背景色は変わります。
+ウェブデバッグツールバーのそれぞれのパネルはタイトルの背景色に影響を及ぼすステータスを指定できるようになりました。たとえば、`sfLogger::INFO`
よりも優先順位が高いメッセージがロギングされている場合、log パネルのタイトルの背景色は変わります。
### `sfWebDebugPanel` リクエストパラメータ
@@ -930,7 +930,7 @@
### スロットの改善
-スロットが提供されない場合、`get_slot()` と `include_slot()`
ヘルパーは戻り値として返すスロットのデフォルトの内容を指定するための2番目のパラメータを受け取ります:
+スロットが提供されない場合、`get_slot()` と `include_slot()`
ヘルパーは戻り値として返すスロットのデフォルト内容を指定するための2番目のパラメータを受け取ります:
[php]
<?php echo get_slot('foo', 'bar') // foo スロットが定義されていなければ bar が出力される ?>
@@ -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-17 23:11:52 UTC
(rev 28597)
+++ doc/branches/1.4/tutorial/ja/which-version.markdown 2010-03-18 07:16:27 UTC
(rev 28598)
@@ -1,13 +1,13 @@
どちらのバージョンを選べばよいのか？
==================================
-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.4 は両方とも同じ時期 (2009年末)
にリリースされ、実際のところ、これらは両方とも**まったく同じ機能一式**を備えています。2つのバージョンの唯一の違いは symfony
の古いバージョンとの後方互換性のサポートです。
-symfony 1.3 は古い symfony のバージョン (1.0、1.1 もしくは 1.2)
を使うレガシープロジェクトをアップグレードする場合に選びたいリリースです。これは 1.3
の開発期間に廃止予定の後方互換性レイヤーとすべての機能を備えています。このことはアップグレードが楽でシンプルであり、そして安全でもあることを意味します。
+symfony 1.3 は古い symfony のバージョン (1.0、1.1 もしくは 1.2)
を使うレガシープロジェクトをアップグレードする場合に選ぶリリースです。これは廃止予定であるがまだ利用可能な後方互換性レイヤーとすべての機能を備えています。このことはアップグレードが楽でシンプルであり、そして安全でもあることを意味します。
-今日新しいプロジェクトを始めるのであれば、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
に移行するための時間は十分にあります。
--
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.
