blog@longkey1.net

CakePHP1.3でControllerのテストは基本的にtestAction()使わないと始まらないんだよね。

とあるメールフォームで確認画面かどうかを

$this->param['form']['confirm']

を見て、切り替えたりしているんだけど、$this->paramへの値の渡し方がわからない。
マニュアル見ても$this->dataしか載ってない気が。。。
頑張ってcake_test_case.phpのtestActionメソッドの箇所も読んでみたけど難しそうかなーと思って、駄目元でちょうど開催されていたCakePHPのIRC集会で聞いてみたら、なんと解決策が！
さすが猛者が集まるIRC！

$this->testAction($url, array('method' => ... , 'form' => array('hoge' => 'value')))

formって入れちゃえば良いのね。
結果これでちゃんと動きました。
動いたことを踏まえてソースを読んでみると、349行目にこんな記述が。

# cake_test_case.php

$params = array_diff_key($params, array('data' => null, 'method' => null, 'return' => null));

多分、form以外も受け取ってくれそうな感じがする（未検証）。

IRCで快く相談に乗ってくださったnojimageさんありがとうございました！
めちゃくちゃ助かりました！
勉強になりました！

CakePHP1.3でAuthコンポーネントを使用しているControllerでtestActionを使うと、ログインしていなければ、普通にログイン画面へリダイレクトされる。
これじゃテストにならない。

いろいろ試行錯誤してみたけど、直接Sessionにログインユーザーの情報をセットしてあげれば良いみたい。

■参考サイト
Testing CakePHP Controllers the hard way | Mark Story

$this->{Controller名}->Session->write('Auth.User', array(
	'id' => 'hogehoge',
	'username' => 'hogehoge',
	'role' => 'hogehoge',
));

$this->testAction($url, array(...));

まさかのやり方。
これは知らないと出来ないと思うんだけどなー。
日本語サイトでは情報は皆無だったので、英語サイトで探してみたらすぐ見つかった。
英語サイトも読むようにしなければ。

「第5回CakePHP勉強会@Tokyo 東海サテライト」に行ってきました。
個人的に非常に久しぶりの勉強会ということで、ドキドキしながら会場に向かいました。

第5回CakePHP勉強会@Tokyo自体がUstreamで配信されるということで、家でも見れたんだけど、名古屋でCakePHPのイベントは初めてだし、PHPerと絡みたいと思って行ってきました。

冒頭に少しだけ東京の会場から呼び掛けがあり、ちょっとテレビ中継みたいで楽しかった。
時代の進化はすごい、昔はテレビ局しかできなかったことが、今は素人が出来てしまうんだから。

サテライトというやり方は、最初どうなのかなって思ったんだけど、結構良かったんじゃないかというのが、僕の感想。
発表の合間合間に、前の発表に関する意見交換があったりして、一人で見ていると「あれってなんだろ？」ってのが、みんなの反応が見られるというのが新鮮でした。
もっと、ヤジみたいなのがあっても良かったのかなと。
どうせ聞こえないんだしさ。
行儀良すぎだったかな。

次回は同じ会場が使えない可能性が高いということで、開催が難しいかもしれないとのこと。
なんとか続けてもらえたらなと思います。

以下、第5回CakePHP勉強会@Tokyoの感想
■CakePHP1.3の概要(仮) 市川さん(@cakephper)
・結構知っていることも多かったかなという印象。
・CakePHP1.3のバリデーションにdatetimeを入れてくれても良かった気が・・・。
・プレゼン資料も文字が大きめで分かりやすかった。

■Ktai Library on CakePHP1.3(仮) 滝下さん(@ecworks_masap)
・来週名古屋に来ていただけるということで楽しみ！
・ざっくりとした内容の発表で、これまた大体知っている感じでした。
　けど、作者の方からの説明ってのは、やっぱり空気感が伝わって良いなとも思いました。

■コアライブラリのエレガントなハック 清水紘己さん(hiromi)
・正直難しかったし、良くわからなかった。
・すごく深い階層の話をしていて、ソースを追っていない部分に関しては全くわからなかったのが残念。
・発表者の方も言っていたけど、僕は今のところCakePHPのコアライブラリに関するハックというのは、懐疑的かな。多分、そこまでしないといけないような仕様の場合は、他のフレームワークを使うだろうし、既にあるシステムの場合でもな・・・。
・CakePHP2.0になると、そういった部分が考慮されてくるのかな？


■ツイート君というtwitterの外部アプリを作った際に、直面した様々な問題についての説明。
・顔は一切写らなかったのでわからなかったけど、イケメンそうだった。
・ツイート君の解析アルゴリズムはすげー気になったけど難しそう。
・CakePHPって簡単！と言われると、そうそうと思いつつも誰でも使いこなせる危機感も同時に募るのが・・・。

今回の一番の収穫は、名古屋にもCakePHPをひっそりと使っている人が、少しだけいた事を確認できたことかな。
懇親会もプログラミングの話から、仕事についての話まで幅広く話すことが出来て良かったなと。
今後は僕も何かしらサポート出来たらなと思いました。

※2010/5/17 追記 Ktai Library0.3.2にてこのバグは対応済みです

CakePHP1.3＆Ktai Library0.3で、Layoutを使うと文字コードが変換されないという現象を確認。
多分CakePHP1.2でも同じ現象かと。

ソースをみてみたところ、KtaiHelper::afterLayout()で文字コードを変換している模様。
ここで変換してしまうと、レイアウトを使用していない場合は処理通らない。

ということで、この辺のフック処理の順番を調べてみた。
最初はKtaiHelper::afterRender()に書き換えればいいかなと思ったんだけど、ここに書くと今度はレイアウトを利用している時に、レイアウトに適用されない。

なので方法論としては二つあると思う。
A) レイアウト利用時も利用していない時も通るところで変換する
B) それぞれの場所で変換処理を行い、既に変換処理を行った場合はしないように分岐する

A)の場合
実質、Controller::afterFilter()しかない。
が、ここでやってしまうと大雑把過ぎるというか、今まで出来ていた「このViewの時だけ変換しない」みたいなことを、気軽にViewファイルに書けなくなった。
これは面倒だなと。
ということで、B)のやり方でもやってみた。
CakePHPのソースを久しぶりにこんなに追ったなー。

@KtaiHelper

var $options = array(
	'img_emoji_url' => "/img/emoticons/", 
 
	'output_auto_encoding' => false, 
	'output_auto_convert_emoji' => false, 
	'output_convert_kana' => false, 
	'output_use_layout' => true, //追記
);

function afterRender(){
	parent::afterRender();

	// convert, encoding, shutdown
	if(!$this->options['output_use_layout']){
		$this->_shutdown();
	}
}

function afterLayout(){
	parent::afterLayout();

	// convert, encoding, shutdown
	if($this->options['output_use_layout']){
		$this->_shutdown();
	}
}

function _shutDown(){
	$out = ob_get_clean();
	$input_encoding  = $this->options['input_encoding'];
	$output_encoding = $this->options['output_encoding'];
	
	if($this->options['output_convert_kana'] != false){
		$out = mb_convert_kana(
			$out, 
			$this->options['output_convert_kana'], 
			$input_encoding
		);
	}
	
	if($this->options['output_auto_convert_emoji']){
		$this->convert_emoji($out);
	}else{
		if($this->options['output_auto_encoding'] && 
			($input_encoding != $output_encoding)){
			$out = mb_convert_encoding(
				$out, 
				$output_encoding, 
				$input_encoding
			);
		}
	}
	
	ob_start();
	echo $out;
	
	$this->_lib3gk->shutdown();
}

見てもらえたら直ぐ分かると思うんだけど、以下のことをやっている。

・$optionsのパラメータ（output_use_layout）を一つ追加
・追加した$options['output_use_layout']を見て、レイアウトを使っているかどうか分岐。使っているならtrue（デフォルト）、使ってないならfalse。
・分岐先の処理は、以前afterLayoutで使われていた変換処理をそのまま流用

どっかにlayoutを使っているかどうかわかる変数がないかなーと思って探してみたけど無さそうだったし、この辺仕様変更で影響を受けるのも勘弁して欲しいところだと思うので。

これで、Layoutを使ってないviewファイルに

$ktai->options['output_use_layout'] = false;

なんて書いちゃえばOK。
んー、お手軽。

とりあえず応急処理はこんな感じで。
作者の方もこの不具合は把握しているそうので、次のバージョンでは解決されると思われる。

期待してます！

layout機能をオフにしているViewに$scripts_for_layoutを使おうとするとエラーになる。

Undefined variable: scripts_for_layout...

考えてみれば当たり前の話だ。
layout機能を使っている場合は、layoutに追記したい時もあるんだろうけど、使って無いなら直接書けばいいんだから。

以上。