プロジェクトをsymfony 1.1 から 1.2へアップグレード(UPGRADE_TO_1_2)
このファイルは http://trac.symfony-project.org/browser/branches/1.2/UPGRADE_TO_1_2 の翻訳です。
リビジョン: 12542
(注意)
このページはUPGRADE_TO_1_2(日本語訳)の体裁を整え読みやすくした記事です。
正式リリースまでに内容に修正がある場合があります。正確な情報はソースに含まれるUPGRADE_TO_1_2ファイルを確認するようにしてください。
プロジェクトを1.1から1.2へのアップグレード
このドキュメントではsymfony 1.2における変更点とsymfony1.1で作成したプロジェクトをアップグレードするためにどうする必要があるかについて記述しています。
もし、symfony 1.2で追加、変更されたことについてもっと詳細な情報が必要な場合はWhat's new? ページを読んでください。
（日本語訳は 日本語翻訳プロジェクトページ かこのサイト内 で閲覧可能です）
注意
symfony1.2はPHP5.2.4以降と互換があります。
PHP5.2.0から5.2.3でも動作するかもしれませんが保証はありません。
どうやってアップグレードするの？
プロジェクトをアップグレードするために:
* もしSCMツールを使っていないのなら、あなたのプロジェクトをバックアップしておいてください。
* `project:upgrade1.2`をプロジェクトディレクトリから実行し、自動的に行われるアップグレードを完了してください。
$ php symfony project:upgrade1.2
このタスクはどこにも影響させずに数回実行することができます。新しいsymfony1.2 beta /RC または最終的なsymfony1.2 へアップグレードするたびに、
このタスクを実行しなければなりません。
* モデルとフォームに変更を行うために次のタスクを実行し再構築する必要があります。
$ php symfony propel:build-model
$ php symfony propel:build-forms
$ php symfony propel:build-filters
* キャッシュをクリアします。
$ php symfony cc
残りのセクションでは(自動でアップグレードされる点と手動でしなければならない)アップグレードが必要なsymfony1.2での主な変更点について説明します。
Upgrade to 1.2 final
もし、最終的なリリースである1.2より前に1.1のプロジェクトをアップグレードしている場合は、以下のことを確認してください。
- CRUDモジュールを`--non-verbose-templates`オプションを指定して生成していたならば、`$form->renderHiddenFields()`を`_form.php`テンプレートから削除しなければなりません。そうしないと"CSRF attack detected"というエラーメッセージが出てしまいます。
- 全ての生成されたCRUDモジュールのために、CSRFプロテクションを有効にするなら、CSRF攻撃から守るたえmに`$request->checkCSRFProtection()`メソッドを生成された`excuteDelete()`メソッドの先頭に挿入するにひつようがあります。
Propel
Propelはバージョン1.3にアップグレードされました。このバージョンではCreoleに代わりPDOがサポートされています。
Creoleを除去するために、以下のクラスを移動させなければなりません。
| クラス名 | 同義(equivalent) |
|---|---|
| sfCreoleDatabase | sfPropelDatabase |
| sfDebugConnection | DebugPDO |
| sfMessageSource_Creole | sfMessageSource_PDO |
| sfCreoleSessionStorage | sfPDOSessionStorage |
`propel:build-db` タスクの機能は Propel 1.3で提供されていない機能なので取り除かれました。
アップグレードするための最初のステップは `databases.yml` ファイルのデータベースの設定部分においてCreoleをPDOの構文に変更することです。
以下の部分を
-
...
-
all:
-
propel:
-
class: sfPropelDatabase
-
param:
-
dsn: mysql://username:password@localhost/example
次のように書き換えます。
-
...
-
dev:
-
propel:
-
param:
-
classname: DebugPDO
-
-
test:
-
propel:
-
param:
-
classname: DebugPDO
-
-
all:
-
propel:
-
class: sfPropelDatabase
-
param:
-
dsn: mysql:dbname=example;host=localhost
-
username: username
-
password: password
-
encoding: utf8
-
persistent: true
-
pooling: true
-
classname: PropelPDO
次に、 PDOフォーマットのDSNと設定のオプションを最新にするために、`propel.ini` もアップグレードしなければなりません。
以下の部分を
...
propel.database = mysql
propel.database.createUrl = mysql://username:password@localhost/
propel.database.url = mysql://username:password@localhost/example
次のように書き換えます。
...
propel.database = mysql
propel.database.driver = mysql
propel.database.url = mysql:dbname=example;host=localhost
propel.database.user = username
propel.database.password = password
propel.database.encoding = utf8
基礎となるapiがほんの少し変更されているので、オブジェクトモデルを再構築する必要があります。
$ php symfony propel:build-model
ほとんどの場合、これら全ての変更が必須です。もしオブジェクトモデルクラスをカスタマイズしているならば
CreoleをPDOにAPIを変更するために手動でアップグレードが必要になるかもしれません。
アップグレードタスクは `永続的な(Persistent)` インターフェースに一致するメソッドに変更を行おうとします。
それは、PropelPDOのために `->save($con = null)` と `->delete($con = null)` にタイプヒンティングを追加することによってです。
たとえば次のような場合に行われる変更は
-
...
-
public function save($con = null)
-
public function delete($con = null)
次のようにPropelPDOタイプヒンティングを追加することです。
-
...
-
public function save(PropelPDO $con = null)
-
public function delete(PropelPDO $con = null)
トランザクションapiはわずかに変更が行われます。それは `->begin` は `->beginTransaction()`に、そして
`->rollback()`は`->rollBack()`に変更されることです。以下がその違いです。
`Creole`:
-
...
-
$con->begin();
-
try {
-
/* db logic */
-
-
-
$con->commit();
-
} catch (SQLException $sqle) {
-
$con->rollback();
-
throw $sqle;
-
}
`PDO`:
-
...
-
$con->beginTransaction();
-
try {
-
/* db logic */
-
$con->commit();
-
} catch (PDOException $sqle) {
-
$con->rollBack();
-
throw $sqle;
-
}
`::doSelectRS`メソッドは `::doSelectStmt`に変更されます。以下がその違いです。
`Creole`:
-
...
-
// example of how to manually hydrate objects
-
$rs = AuthorPeer::doSelectRS(new Criteria());
-
while($rs->next()) {
-
$a = new Author();
-
$a->hydrate($rs);
-
}
-
-
// example of how to create array of single column
-
$rs = AuthorPeer::doSelectRS(new Criteria());
-
while($rs->next()) {
-
$names[] = $rs->getString(2);
-
}
-
-
$con = Propel::getConnection(SomeTablePeer::DATABASE_NAME);
-
$stmt = $con->prepareStatement("SELECT * FROM some_table WHERE name = ?");
-
$stmt->setString(1, $name);
-
$rs = $stmt->executeQuery();
-
while($rs->next()) {
-
}
`PDO`:
-
...
-
// example of how to manually hydrate objects
-
$stmt = AuthorPeer::doSelectStmt(new Criteria());
-
while($row = $stmt->fetch(PDO::FETCH_NUM)) {
-
$a = new Author();
-
$a->hydrate($row);
-
}
-
-
// example of how to create array of single column
-
$stmt = AuthorPeer::doSelectStmt(new Criteria());
-
while($res = $stmt->fetchColumn(1)) {
-
$names[] = $res;
-
}
-
-
$con = Propel::getConnection(SomeTablePeer::DATABASE_NAME);
-
$stmt = $con->prepare("SELECT * FROM some_table WHERE name = ?");
-
$stmt->bindValue(1, $name);
-
$stmt->execute();
-
while($row = $stmt->fetch()) {
-
}
更なるアップグレードの詳細についてはhttp://propel.phpdb.org/trac/wiki/Users/Documentation/1.3/Upgrading を見てください
全てのPropelライブラリは `lib/propel`から `lib` に移動しました。アップグレードタスクは `propel.ini`
ファイルにこれらの変更を反映するためにアップグレードします。
リクエスト(Request)
`path_info_array`、`path_info_key` そして `relative_url_root` セッティングは `settings.yml`
から `factories.yml` (`request` ファクトリ設定の `param` セクション)に移動しました。
この変更は `sfRequest` と `sfConfig` の間の依存を取り除きます。
レスポンスは新しいメソッドを持つようになりました。それは`getCharset()`です。これは現在のレスポンスの文字コードを返します。
もし、コンテントタイプのcharsetを変更するとこのcharsetは自動的にアップデートされます。
これらの3つのリクエストオプションはリクエストコンストラクターに４番目の引数として渡されるようになりました。
そのフォーマットも属性としてではなく、オプションとして渡されます。
`sfRequest`からのリクエストメソッドの定数の値は数値から文字列に変更になり、`sfRequest::NONE`メソッドは取り除かれました。
| 定数 | 旧 | 新 |
|---|---|---|
| GET | 2 | GET |
| POST | 4 | POST |
| PUT | 5 | PUT |
| DELETE | 6 | DELETE |
| HEAD | 7 | HEAD |
| NONE | 1 | - |
`getMethod()` と `getMethodName()` メソッドは同じ値を返すようになり、
それに伴い `getMethodName()`は廃止される予定です。
`sfAction::getMethodNames()` と `sfCompat10plugin`から`sfValidationExecutionFilter`にある
相当するコードを取り除きます。
このメソッドは1.1で廃止予定だったものであり本当は1.0で利用できないものです。
バリデーター(Validators)
`sfValidatorSchemaCompare`定数は変更されました。コードに変更は必要ありません。しかしこれからは、
すばらしいショートカットを使う事ができます。
次の２つの例が実装例です。
-
...
-
// symfony 1.1 and 1.2
-
$v = new sfValidatorSchemaCompare('left', sfValidatorSchemaCompare::EQUAL, 'right');
-
-
// symfony 1.2 only
-
$v = new sfValidatorSchemaCompare('left', '==', 'right');
symfony1.1では`sfValidatorI18nChoiceCountry`と`sfValidatorI18nChoiceLanguage`バリデーターは
`culture`オプションが必須でした。この`culture`はこれらのバリデーターで使われていないので、
`culture`オプションは廃止される予定です。後方互換性のためにまだ残っていますが、もう使う必要はありません。
フォーム (Forms)
symfony1.1では `BaseFormPropel`が間違った場所(`lib/form/base`ディレクトリ)に生成されていました。
そのためこのファイルを`lib/form`ディレクトリに移動させる必要があります。
ウィジット（Widgets）
新しい`sfWidgetFormChoice`ウィジットは標準ではPropelが`sfWidgetFormSelect`の代わりに生成するフォームで利用されるようになりました。
よりパワフルなウィジットを利用するためにはフォームを再構築する必要があります。
レスポンス（Response）
`response`ファクトリのための新しい設定があります。それは`send_http_headers`です。
この設定はヘッダーがPHPによって送信されるべきでない`test`環境以外において標準では`true`に設定されています。
(同様の目的のためにsymfony 1.1では `sf_test`の設定が使われていました)
もし`sfWebResponse::ALL`を最初の引数として渡せば
`getStyleSheets()`と`getJavascripts()`メソッドは現在は全てのスタイルシートとJavaScriptをポジションで指定された順番で返します。
-
...
-
$response = new sfWebResponse(new sfEventDispatcher());
-
$response->addStylesheet('foo.css');
-
$response->addStylesheet('bar.css', 'first');
-
-
-
// outputs
-
)
`sfWebResponse::ALL`はポジションの引数のための標準の値でもあります。
symfony 1.1 では標準の値は空の文字列だったため、標準では標準のポジションのために
登録されたファイルだけを返し、直感的ではありませんでした。
symfony1.1では、'ALL'という文字列をポジションとして渡すことで全てのファイルを取得することができました。
そしてこの挙動は`sfWebResponse::RAW`を渡す事でまだ利用できます。
全てのポジション (first, '' そして last)も定数で利用することができます。
-
...
-
sfWebResponse::FIRST === 'first'
-
sfWebResponse::MIDDLE === ''
-
sfWebResponse::LAST === 'last'
`removeStyleSheet()`と`removeJavascript()`メソッドは１つの引数だけをとることができ、
それはレスポンスから取り除くためのファイルです。全ての利用可能なポジションにあるファイルを取り除くことができます。
symfony1.1では第２引数としてポジションを渡していました。
Prototype と Scriptaculous
symfonyはバンドルされたソフトウェアを切り離し続けています。1.2においてバンドルされていたPrototypeと
Scriptaculousライブラリとヘルパー(`JavascriptHelper`)はコアプラグインに移動されました。
コアプラグインは本物のプラグインのように振る舞いますが、symfonyプラットフォームによって操作されます。
これはjavascriptファイルと`sfProtoculausPlugin`(多かれ少なかれ非公式な機能の２重奏としての名前)というの新しいcssファイルを作ります。
これは本物のプラグインのような新しい`sfProtoculousPlugin`というCSSファイルを作成します。
それらは (1.0や1.1のときに配置されていた)`web/sf`ディレクトリではなく`web/sfProtoculousPlugin`ディレクトリに配置されることになります。
`prototype_web_dir`設定により新しいディレクトリを指定することができるようにもなります。
さらに、色々なJSフレームワークによって利用される基本的なJavascriptヘルパーがコア部分に`JavascriptBaseHelper`として抽出されます。
新しいこととして、`javascript_tag()`は`slot()`のように動作するようになります。次のような使い方ができます。
-
...
-
<?php javascript_tag() ?>
-
alert('All is good')
-
<?php end_javascript_tag() ?>
組み込みプラグインからの資産
組み込みプラグインの中にはスタイルシートやJavaScriptファイルが含まれているものがあります。
プロジェクトでこれらを利用できるようにするために、`plugin:publish-assets`タスクを走らせる必要があります。
$ php symfony plugin:publish-assets
`project:upgrade1.2`タスクはあなたに代わってこれを行ってくれます。
ブラウザー(Browser)
`sfBrowser`と`sfTestBrowser`クラスは４つのクラスにリファクタされました。
| sfBrowserBase | 基礎となるブラウザークラスです。symfonyの環境からのクラスを除いてsymfonyについては何もしりません。 |
| sfBrowser | `sfBrowserBase`を継承しており、symfonyの関するメソッドを実装しています。 |
| sfTestFunctionalBase | 基礎となる機能テストクラスです。symfonyから独立しているテストメソッドを実装しています。 |
| sfTestFunctional | sfTestFunctionalBase`クラスを継承しておりsymfonyに関するテストメソッドを実装しています。 |
| sfTestBrowser | `sfTestFunctional`クラスと同じBC(後方互換性)のクラスであり、symfony 1.1互換のあるコンストラクターのクラスになっています。 |
リファクタリングの背景にある考えは、`sfTestFuntional`クラスはテストクラスでありブラウザーではないということです。
そのため、次のように引数としてブラウザーとテストオブジェクトを持っています。
-
...
-
$testBrowser = new sfTestBrowser('localhost');
-
-
$tester = new sfTestFunctional(new sfBrowser('localhost'), new lime_test());
`sfTestFunctional`クラスはブラウザークラスのためのプロキシのように活動し、これは全ての
ブラウザーからのメソッドは直接テストオブジェクトからアクセスすることができるということを意味します。
このリファクタリングがsymfony1.1と互換性がないものになってはいけません。
ブラウザークラスは各リクエストのために`HTTP_REFERER`を追加するようになりました。
テスト(Tests)
Testers
`sfTestFunctionalBase`クラスは実際のテストを`sfTester`クラスに委任するようになりました。
symfony 1.2はいくつかの組み込みテスタークラスがあります。
| `request` | `sfTesterRequest` |
| `response` | `sfTesterResponse` |
| `user` | `sfTesterUser` |
| `view_cache` | `sfTesterViewCache` |
全ての古いテストブラウザのメソッドはテスタークラスのメソッドに移動されました。
| method name | tester class | new method name |
|---|---|---|
| `isRequestParameter` | `sfTesterRequest` | `isParameter` |
| `isRequestFormat` | `sfTesterRequest` | `isFormat` |
| `isStatusCode` | `sfTesterResponse` | `isStatusCode` |
| `responseContains` | `sfTesterResponse` | `contains` |
| `isResponseHeader` | `sfTesterResponse` | `isHeader` |
| `checkResponseElement` | `sfTesterResponse` | `checkElement` |
| `isUserCulture` | `sfTesterUser` | `isCulture` |
| `isCached` | `sfTesterViewCache` | `isCached` |
| `isUriCached` | `sfTesterViewCache` | `isUriCached` |
テスタークラスも新しいメソッドが用意されました。
| tester class | new method name |
|---|---|
| `sfTesterRequest` | `hasCookie` |
| `sfTesterRequest` | `isCookie` |
| `sfTesterRequest` | `isMethod` |
| `sfTesterUser` | `isAuthenticated` |
| `sfTesterUser` | `hasCredential` |
| `sfTesterUser` | `isAttribute` |
| `sfTesterUser` | `isFlash` |
古いメソッドは廃止されたとしても、symfony1.0と1.1の互換性のために警告は発生せず取り除かれるようになります。
リンク(Links)
リンクになっているクリックやボタンをシミュレーションするとき、`click()`メソッドという名前を使います。
しかし、同じ名前で２つの異なるリンクやボタンを差別化するほうほうがありません。
symfony 1.2 では `click()`メソッドではオプションを第３引数に渡します。
`position`というオプションをクリッックしたいしたいリンクを変更するときに渡します。
標準で、symfonyはページにある項目の最初のリンクをクリックします。
`method`オプションでクリックしたいリンクやフォームのメソッドを変更することができます。
これはリンクがJavascriptで動的に生成されるフォームで変換される場合に役立ちます。
アクション(Actions)
標準で、`redirectIf()`や``redirectUnless()'メソッドをアクションの中でつかうとき、
symfonyはHTTPレスポンスのステータスを自動的に302に変更します。
これらの２つのメソッドは追加のおpションを持つようになり、この標準のステータスコードを変更できるようになりました。
-
$this->redirectIf($condition, '@homepage', 301);
-
$this->redirectUnless($condition, '@homepage', 301);
`redirect()`メソッドにおいては既にこの機能は実装されています。
コンポーネント
エスケープ出力を有効にしているならば、symfony1.0と1.1ではバグがありました。
アクションからコンポーネントに値を渡すと、エスケープされた値がコンポーネントに渡されていました。
そのため、状況によってはアンエスケープの処理が必要でした。
-
...
-
public function executeInAComponent($request)
-
{
-
$this->foo = $this->foo->getRawValue();
-
}
symfony1.2では修正され、コンポーネントメソッドでは標準で新しいエスケープされていない変数が利用できるようになりました。
上の例のような、あなたに変わり自動的にフレームワークが行うように`getRawValue()`処理を削除する必要があります。
sfParameterHolder
The `sfParameterHolder`の`has()`メソッドはよりその本来の正しい動作になるように変更されました。
もし値が`null`だった場合は`true`を返すようになりました。
-
$ph = new sfParameterHolder();
-
$ph->set('foo', 'bar');
-
$ph->set('bar', null);
-
-
$ph->has('foo') === true;
-
$ph->has('bar') === true; // returns false under symfony 1.0 or 1.1
`sfParameterHolder::has()`メソッドは多くのコアクラスの中で`hasParameter()`や
`hasAttribute()`メソッドで利用されています。
タスク(Tasks)
取り込まれているPhingタスクが失敗するなら、Phingに依存しているPropelタスクははっきりとした
エラーメッセージを出力します。
CLIタスクの中にはアプリケーション名を引数として必要としているものがあります。なぜなら
それらはデータベースに接続する必要があるからです。アプリケーション上でカスタマイズされる設定ファイルが必要なため
私たちはアプリケーションが必要なのです。そして全てのsymfonyの設定システムはアプリケーションレベルが基礎となっています。
これらのタスクにとって、引数はオプションである"application"オプションになって取り除かれました。
もし、"application"オプションを提供しないならsymfonyはプロジェクトの`databases.yml`ファイルから
データベース設定を取得してくるようになりました。
次のタスクの用法はこれらに従って変更されました。
- `propel:build-all-load`
- `propel:data-dump`
- `propel:data-load`
ノート
これは`sfDatabaseManager`が今ではプロジェクト設定やアプリケーション設定を取得するようになったので可能になりました。
興味深いこととで、`sfDatabaseConfigHandler`は今では静的か動的な設定ファイルの配列に基づく設定を返すから動作するのです。
(`exeute()`か`evaluate()`を見てください)
`propel:insert-sql`タスクは全てのデータをデータベースから取り除きます。
情報を破壊するので、タスクの実行前にユーザーに訪ねるようになりました。
同じことが`propel:build-all`と`propel:build-all-load`タスクにもあてはまります。
もし、これらのタスクをバッチ処理で使いたいなら確認のための質問を避けたいでしょう。そのときは
`no-confirmation`オプションを渡してください。
$ php symfony propel:insert-sql --no-confirmation
symfony 1.2より前では、`propel:insert-sql`タスクは`propel.ini`からのデータベースの情報を読み取ることしかしませんでした。
symfony 1.2では`databases.yml`から読みとるようになりました。そのため、モデルに複数の異なる接続先を設定したいなら
このタスクはそれらを考慮するようになりました。
この新しい機能のおかげで、 もし指定した接続先からのSQLだけを読み込みたい場合に
`--connection` オプションを使う事ができるようになりました。
$ php symfony propel:insert-sql --connection=propel
また`--env`と`--application`オプションも次のように特定の設定を選択するために使う事ができます。
$ php symfony propel:insert-sql --env=prod --application=frontend
`propel:generate-crut`は`propel:generate-module`に名前が変更されました。
古いタスク名はエイリアスとしてまだ利用することができます。
`propel:generate-module`タスクの`non-atomic-actions`オプションは取り除かれ次のような新しいオプションが追加されました。
- singular:
- アクションとテンプレートのための単数形名
- plural:
- アクションとテンプレートのための複数形名
- route-prefix:
- 使用されるルーティングの接頭辞
- with-propel-route:
- propelのルーティングを使うかどうか
デバッグのために、`propel;build-model`, `propel:build-all`そして
`propel:build-all-load`タスクは `--trace`オプションを指定すれば生成されるスキーマを取り除きません。
URLヘルパー(URL helpers)
`link_to`の古い`post`はまだ有効ですが廃止する予定です。
`ulf_for()`と`link_to()`ヘルパーは新しい特徴をサポートするようになりました。
内部URIの代わりに、ルーティング名とパラメータの配列もとることができます。
何も変更を加えなくてもこれまでの設定は動作します。
イメージヘルパー(Image helper)
symfony 1.0と1.1では `image_tag`ヘルパーはファイル名からimgタグの`alt`属性を生成しています。
これからは`sf_compat_10`が有効になっているときにだけこのように動作します。
これからは(x)htmlバリデーターが使っているセットされていないalt属性を簡単に見つけることができます。
さらに、新しい`alt_title`オプションによってaltをセットし、タイトル属性を同じ値にすることができます。
これはクロスブラウザーでのツールチップとして利用できます。
ビュー(View)
標準の`sf_cache_namespace_callable`設定で`sfViewCacheManager::generateCacheKey()`
を上書きすることができます。
symfony1.2では、collableは追加の引数のビュークラスインスタンスで呼び出されるようになりました。
設定(Configuration)
symfony 1.2より前は、全てのプラグインは`plugins`ディレクトリにインストールされていました。
そして、全ての組み込みプラグインは自動的に読み込まれていました。
symfony 1.2では、あなたのプロジェクトの穴kで利用したいプラグインを有効にする必要があります。
`ProjectConfiguration`クラスでこれを行うことができます。
以下がDoctrineプラグインを有効にし、Propelプラグインを無効にする方法です。
-
public function setup()
-
{
-
$this->enablePlugins('sfDoctrinePlugin');
-
$this->disablePlugins('sfPropelPlugin');
-
}
複数のプラグインを一度に追加する倍はプラグイン名の配列を渡します。
-
public function setup()
-
{
-
}
`setPlugins`メソッドを用いることでプラグインの読み込まれる順番を変更することができます。
-
public function setup()
-
{
-
}
`settings.yml`にあった`orm`設定は自動的にORMプラグインが読み込まれるときにセットされるようになったので廃止される予定です。
`settings.yml`設定にある`compat_10`設定も廃止される予定です。これは`sfCompat10Plugin`が読み込まれたときに
自動的にセットされるようになったからです。
そのため、1.0と互換性のあるプラグインを有効にするために、設定で次のように有効にする必要があります。
-
public function setup()
-
{
-
$this->enablePlugins('sfCompat10Plugin');
-
}
標準では、symfonyはPropelプラグインだけが有効です。
全てのインストールしたプラグインも有効にすることができます。
-
public function setup()
-
{
-
$this->enableAllPluginsExcept('sfDoctrinePlugin');
-
}
上のようにしてDoctrineプラグイン以外の全てのプラグインを有効にすることができます。
1.0または.1.1からアップグレードする場合は、この行によってsymfony 1.0と1.1のときのようにsymfonyを動作させることができます。
`sfLoader`クラスは廃止される予定で、`getHelperDirs()`と`loadHelpers()`メソッドはこれからは
`sfAplicationCOnfiguration`クラスの一部になります。
`sfLoader`メソッドは廃止予定である旨のメッセージを生成し新しいメソッドを呼び出します。
プラグインの設定
プラグインはプラグインを設定するクラスのためオプションが存在します。
これらのプラグイン設定クラスはプラグインのためにオートローディングを設定し、`sfProjectConfiguration`にインストールされています。
symfony1.2タスクはプラグインクラスが仕様するアプリケーション名をもはや必要としません。
プラグインは`command.*`イベントに接続することで以前はできなかったことができるようになりました。
国際化(I18N)
内部的に、`sfCulterUnfo`クラスはこれらかはシングルトンとしてのみ利用できるようになります。
`getInstance()`メソッドをバイパスすることが可能で、新しいオブジェクトを直接インスタンス化することができるとしても
廃止される予定です。
シングルトンとして利用するために、１リクエストの度に１つのカルチャーについての情報をインスタンス化するためパフォーマンスは向上し、
設定クラスの中でグローバルにカルチャーについて上書きする事ができるということです。
`sfCulterInfo::getCountries()`と`sfCulterInfo::getCurrencies()`そして`sfCultureInfo::getLanguages()`メソッドは
戻り値を制限するためのオプションの引数をとることができるようになりました。
-
// will only return the FR and ES countries in english
`sfCulterInfo::getCurrencies()`メソッドは通貨名の配列を返します。
以前のバージョンのsymfonyでは、通貨記号と名前の配列を返していました。
以前のような動作をさせるためには、次のように第２引数に`true`を渡すだけです。
-
$currencies = sfCultureInfo::getInstance('en')->getCurrencies(null, true);
１つだけの国、言語、通貨の翻訳を取得するためには、`getCountry()`、`getCurrency()`、`getLanguage()`メソッドを
`sfCultureInfo`クラスから使うことができるようになりました。
テンプレートの例外処理(Exception Templates)
キャッチできないあらゆる発生した例外をレンダー処理するとき、symfonyは現在のリクエストフォーマットを考慮するようになりました。
プロジェクトまたはアプリケーションの`config/error`ディレクトリにテンプレートを追加することで各フォーマットの出力をカスタマイズできます。
例えば、XMLリクエストで発生したキャッチできない例外はアプリケーションがデバッグモード時は`config/error/exception.xml.php`を、
デバッグモードでない場合は`config/error/error.xml.php`をレンダー処理します。
プロジェクトディレクトリ内にカスタマイズした500エラーテンプレートを用意していれば、
それを新しいディレクトリに手動で移動する必要があります。
- symfony 1.1 では `config/error500.php` から `config/error/error.html.php`に
- symfony 1.0 では `web/errors/error500.php` から `config/error/error/html/php`に