|
Upgrade_from_1_1_to_1_2
symfony 1.1から 1.2にプロジェクトをアップグレード
Featured このファイルは http://trac.symfony-project.org/browser/branches/1.2/UPGRADE_TO_1_2 の翻訳です。 リビジョン: 13491 (注意) 正式リリースまでに内容に修正がある場合があります。正確な情報はソースに含まれるUPGRADE_TO_1_2ファイルを確認するようにしてください。 1.1から1.2へのアップグレードこのドキュメントではsymfony 1.2における変更点とsymfony1.1で作成したプロジェクトをアップグレードするためにどうする必要があるかについて記述しています。 もし、symfony 1.2で追加、変更されたことについてもっと詳細な情報が必要な場合はWhat's new? http://www.symfony-project.org/tutorial/1_2/whats-new ページを読んでください。 （日本語訳は http://code.google.com/p/symfony-doc-ja/wiki/whats_new_sf12 で閲覧可能） >注意 >symfony1.2はPHP5.2.4以降と互換があります。 >PHP5.2.0から5.2.3でも動作するかもしれませんが保証はありません。 どうやってアップグレードするの？プロジェクトをアップグレードするために:
$ 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のプロジェクトをアップグレードしている場合は、以下のことを確認してください。
PropelPropelはバージョン1.3にアップグレードされました。このバージョンではCreoleに代わりPDOがサポートされています。 Creoleを除去するために、以下のクラスを移動させなければなりません。
propel:build-db タスクの機能は Propel 1.3で提供されていない機能なので取り除かれました。 アップグレードするための最初のステップは databases.yml ファイルのデータベースの設定部分においてCreoleをPDOの構文に変更することです。 以下の部分を [yml]
all:
propel:
class: sfPropelDatabase
param:
dsn: mysql://username:password@localhost/example次のように書き換えます。 [yml]
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 もアップグレードしなければなりません。 以下の部分を [ini]
propel.database = mysql
propel.database.createUrl = mysql://username:password@localhost/
propel.database.url = mysql://username:password@localhost/example次のように書き換えます。 [ini]
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) にタイプヒンティングを追加することによってです。 たとえば次のような場合に行われる変更は [php]
public function save($con = null)
public function delete($con = null)次のようにPropelPDOタイプヒンティングを追加することです。 [php]
public function save(PropelPDO $con = null)
public function delete(PropelPDO $con = null)トランザクションapiはわずかに変更が行われます。それは ->begin は ->beginTransaction()に、そして ->rollback()は->rollBack()に変更されることです。以下がその違いです。 Creole: [php]
$con->begin();
try {
/* db logic */
$con->commit();
} catch (SQLException $sqle) {
$con->rollback();
throw $sqle;
}PDO: [php]
$con->beginTransaction();
try {
/* db logic */
$con->commit();
} catch (PDOException $sqle) {
$con->rollBack();
throw $sqle;
}::doSelectRSメソッドは ::doSelectStmtに変更されます。以下がその違いです。 Creole: [php]
// 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());
$names = array();
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()) {
print "Name: " . $rs->getString("name") . "\n";
}PDO: [php]
// 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());
$names = array();
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()) {
print "Name: " . $row['name'] . "\n";
}更なるアップグレードの詳細については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メソッドは取り除かれました。
getMethod() と getMethodName() メソッドは同じ値を返すようになり、 それに伴い getMethodName()は廃止される予定です。 sfAction::getMethodNames() と sfCompat10pluginからsfValidationExecutionFilterにある 相当するコードを取り除きます。 このメソッドは1.1で廃止予定だったものであり本当は1.0で利用できないものです。 バリデーター(Validators)sfValidatorSchemaCompare定数は変更されました。コードに変更は必要ありません。しかしこれからは、 すばらしいショートカットを使う事ができます。 次の２つの例が実装例です。 [php]
// 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をポジションで指定された順番で返します。 [php]
$response = new sfWebResponse(new sfEventDispatcher());
$response->addStylesheet('foo.css');
$response->addStylesheet('bar.css', 'first');
var_export($response->getStylesheets());
// outputs
array(
'bar.css' => array(),
'foo.css' => array(),
)sfWebResponse::ALLはポジションの引数のための標準の値でもあります。 symfony 1.1 では標準の値は空の文字列だったため、標準では標準のポジションのために 登録されたファイルだけを返し、直感的ではありませんでした。 symfony1.1では、'ALL'という文字列をポジションとして渡すことで全てのファイルを取得することができました。 そしてこの挙動はsfWebResponse::RAWを渡す事でまだ利用できます。 [php]
var_export($response->getStylesheets(sfWebResponse::RAW));
// outputs
array(
'first' =>
array(
'bar.css' => array (),
),
'' =>
array(
'foo.css' => array(),
),
'last' => array(),
)全てのポジション (first, '' そして last)も定数で利用することができます。 [php]
sfWebResponse::FIRST === 'first'
sfWebResponse::MIDDLE === ''
sfWebResponse::LAST === 'last'removeStyleSheet()とremoveJavascript()メソッドは１つの引数だけをとることができ、 それはレスポンスから取り除くためのファイルです。全ての利用可能なポジションにあるファイルを取り除くことができます。 symfony1.1では第２引数としてポジションを渡していました。 Prototype と Scriptaculoussymfonyはバンドルされたソフトウェアを切り離し続けています。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]
<?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クラスは４つのクラスにリファクタされました。
リファクタリングの背景にある考えは、sfTestFuntionalクラスはテストクラスでありブラウザーではないということです。 そのため、次のように引数としてブラウザーとテストオブジェクトを持っています。 [php]
$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はいくつかの組み込みテスタークラスがあります。
全ての古いテストブラウザのメソッドはテスタークラスのメソッドに移動されました。
テスタークラスも新しいメソッドが用意されました。
古いメソッドは廃止されたとしても、symfony1.0と1.1の互換性のために警告は発生せず取り除かれるようになります。 ### リンク(Links) リンクになっているクリックやボタンをシミュレーションするとき、click()メソッドという名前を使います。 しかし、同じ名前で２つの異なるリンクやボタンを差別化するほうほうがありません。 symfony 1.2 では click()メソッドではオプションを第３引数に渡します。 positionというオプションをクリッックしたいしたいリンクを変更するときに渡します。 [php]
$b->
click('/', array(), array('position' => 1))->
// ...
;標準で、symfonyはページにある項目の最初のリンクをクリックします。 methodオプションでクリックしたいリンクやフォームのメソッドを変更することができます。 [php]
$b->
click('/delete', array(), array('method' => 'delete'))->
// ...
;これはリンクがJavascriptで動的に生成されるフォームで変換される場合に役立ちます。 アクション(Actions)標準で、redirectIf()や``redirectUnless()'メソッドをアクションの中でつかうとき、 symfonyはHTTPレスポンスのステータスを自動的に302に変更します。 これらの２つのメソッドは追加のおpションを持つようになり、この標準のステータスコードを変更できるようになりました。 [php]
$this->redirectIf($condition, '@homepage', 301);
$this->redirectUnless($condition, '@homepage', 301);redirect()メソッドにおいては既にこの機能は実装されています。 コンポーネントエスケープ出力を有効にしているならば、symfony1.0と1.1ではバグがありました。 アクションからコンポーネントに値を渡すと、エスケープされた値がコンポーネントに渡されていました。 そのため、状況によってはアンエスケープの処理が必要でした。 [php]
public function executeInAComponent($request)
{
$this->foo = $this->foo->getRawValue();
}symfony1.2では修正され、コンポーネントメソッドでは標準で新しいエスケープされていない変数が利用できるようになりました。 上の例のような、あなたに変わり自動的にフレームワークが行うようにgetRawValue()処理を削除する必要があります。 sfParameterHolderThe sfParameterHolderのhas()メソッドはよりその本来の正しい動作になるように変更されました。 もし値がnullだった場合はtrueを返すようになりました。 [php]
$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.1sfparameterHolder::has()メソッドは多くのコアクラスの中でhasParameter()や hasAttribute()メソッドで利用されています。 タスク(Tasks)取り込まれているPhingタスクが失敗するなら、Phingに依存しているPropelタスクははっきりとした エラーメッセージを出力します。 CLIタスクの中にはアプリケーション名を引数として必要としているものがあります。なぜなら それらはデータベースに接続する必要があるからです。アプリケーション上でカスタマイズされる設定ファイルが必要なため 私たちはアプリケーションが必要なのです。そして全てのsymfonyの設定システムはアプリケーションレベルが基礎となっています。 これらのタスクにとって、引数はオプションである"application"オプションになって取り除かれました。 もし、"application"オプションを提供しないならsymfonyはプロジェクトのdatabases.ymlファイルから データベース設定を取得してくるようになりました。 次のタスクの用法はこれらに従って変更されました。
>ノート >これは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オプションは取り除かれ次のような新しいオプションが追加されました。
デバッグのために、propel;build-model, propel:build-allそして propel:build-all-loadタスクは --traceオプションを指定すれば生成されるスキーマを取り除きません。 URLヘルパー(URL helpers)link_toの古いpostはまだ有効ですが廃止する予定です。 [php]
// 次は廃止される予定です
<?php echo link_to('@some_route', array('post' => true)) ?>
// 次で同じ実装になります
<?php echo link_to('@some_route', array('method' => 'post')) ?>ulf_for()とlink_to()ヘルパーは新しい特徴をサポートするようになりました。 内部URIの代わりに、ルーティング名とパラメータの配列もとることができます。 [php]
echo url_for('@article', array('id' => 1));
echo link_to('Link to article', '@article', array('id' => 1));何も変更を加えなくてもこれまでの設定は動作します。 イメージヘルパー(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プラグインを無効にする方法です。 [php]
public function setup()
{
$this->enablePlugins('sfDoctrinePlugin');
$this->disablePlugins('sfPropelPlugin');
}複数のプラグインを一度に追加する倍はプラグイン名の配列を渡します。 [php]
public function setup()
{
$this->enablePlugins(array('sfDoctrinePlugin', 'sfGuardPlugin'));
}setPluginsメソッドを用いることでプラグインの読み込まれる順番を変更することができます。 [php]
public function setup()
{
$this->setPlugins(array('sfDoctrinePlugin', 'sfCompat10Plugin'));
}settings.ymlにあったorm設定は自動的にORMプラグインが読み込まれるときにセットされるようになったので廃止される予定です。 settings.yml設定にあるcompat_10設定も廃止される予定です。これはsfCompat10Pluginが読み込まれたときに 自動的にセットされるようになったからです。 そのため、1.0と互換性のあるプラグインを有効にするために、設定で次のように有効にする必要があります。 [php]
public function setup()
{
$this->enablePlugins('sfCompat10Plugin');
}標準では、symfonyはPropelプラグインだけが有効です。 全てのインストールしたプラグインも有効にすることができます。 [php]
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()メソッドは 戻り値を制限するためのオプションの引数をとることができるようになりました。 [php]
// will only return the FR and ES countries in english
$countries = sfCultureInfo::getInstance('en')->getCountries(array('FR', 'ES'));sfCulterInfo::getCurrencies()メソッドは通貨名の配列を返します。 以前のバージョンのsymfonyでは、通貨記号と名前の配列を返していました。 以前のような動作をさせるためには、次のように第２引数にtrueを渡すだけです。 [php]
$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エラーテンプレートを用意していれば、 それを新しいディレクトリに手動で移動する必要があります。
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
► Sign in to add a comment