へびにっき

環境: CakePHP 1.3

CakePHPのModelクラスには直接トランザクションを制御するメソッドがない。そこで例えば次のようにAppModelにメソッドを定義する。

class AppModel extends Model {
    function begin() {
        return $this->getDataSource()->begin($this);
    }
    function commit() {
        return $this->getDataSource()->commit($this);
    }
    function rollback() {
        return $this->getDataSource()->rollback($this);
    }
}

しかしこの方法ではテストがやりにくい。明示的にトランザクションを制御したい時というのは、複数のテーブルにまたがる複雑なロジックを組むことが多いので、commit/rollbackされたことを確認するのにいちいちDBの状態を確認していては手間がかかりすぎる。

そもそも「commitされたらそれまでの実行結果が反映される」「rollbackされたらトランザクション開始前の状態に戻る」というのはDBの機能なので、改めてテストし直す意味はない。アプリケーションのテストとしてはcommit/rollbackが発行されたことさえ分かればいい。

そこでAppModelで定義する代わりに、専用のモデルクラスを作ってそこでメソッドの定義を行うことにした。$useTable を false にしてもDataSource自体は取得できるというのがポイントである。

class TransactionManager extends AppModel {
    var $useTable = false;
 
    function begin() {
        return $this->getDataSource()->begin($this);
    }
    function commit() {
        return $this->getDataSource()->commit($this);
    }
    function rollback() {
        return $this->getDataSource()->rollback($this);
    }
}

これでMockを使ったテストができるようになった。トランザクションを使用する際は ClassRegistry 経由でこのモデルを取得する。

$tx = ClassRegistry::init('TransactionManager');
 
if($tx->begin()) {
  //...
 
  if(doSomething() && $tx->commit()) {
    return $values;
  }
}
$tx->rollback();
return false;

テスト時には ClassRegistry にMockのインスタンスを登録しておいて、begin/commit/rollbackの各メソッドが呼び出されたことだけを調べる。もちろんそれぞれの操作が失敗した場合のテストもできる。

function startTest() {
  $this->tx = new MockTransactionManager;
  ClassRegistry::addObject('TransactionManager', $this->tx);
}
 
function testA() {
  $this->tx->expectOnce('begin');
  $this->tx->setReturnValue('begin', true);
  $this->tx->expectOnce('commit');
  $this->tx->setReturnValue('commit', true);
  $this->tx->expectNever('rollback');
 
  //...
}

環境: CakePHP 1.3

CakeDCのSearchプラグインは、全体としては非常に優れたプラグインなのですが、Prgコンポーネントの機能がどうしても私の使い方には合いませんでした。具体的に言うと

• 検索パラメータの引き継ぎにnamedを使うのは問題が多い（参考）。代わりにQueryStringを使いたい。
• Searchableビヘイビアと同じような内容の $filterArgs を書くのが手間。
• そもそも値の検証や制限はモデルでやるべき、と考える。コンポーネント内でバリデーションを実行したりDBアクセスまでするのは仕事のし過ぎ。

これらの点を解消するため、昔作ったSearchPaginationプラグインを全面改訂して、Searchプラグインと連携できるようにしました。Prgコンポーネントの代わりに使うことができます。

http://github.com/tkyk/cakephp-search-pagination （旧版は 1.2 ブランチを参照）

使い方は非常に簡単で、コントローラの中で SearchPagination コンポーネントの setup メソッドを実行するだけです。

class UsersController extends AppController {
  var $components = array('SearchPagination.SearchPagination');
 
  function search() {
    $this->SearchPagination->setup('User');
    //...
  }
}

これによってQueryStringから検索パラメータが取得され、data[ModelName] に格納されるので、あとはそれを Searchable ビヘイビアの parseCriteria に渡すなどして、検索条件を組み立てます。

function search() {
  $this->SearchPagination->setup('User');
 
  // 常に $this->data['User'] に検索パラメータが入っている
 
  $this->paginate['conditions'] = $this->User->parseCriteria($this->data['User']);
  $this->set('users', $this->paginate('User'));
 
  $this->set('groups', $this->User->Group->find('list'));
}

ビューでは特に何もしなくても自動的に検索パラメータが引き継がれます。普通にFormヘルパーやPaginatorヘルパーを使ってください。

echo "<h2>Search Form<h2>";
echo $this->Form->create('User', array('type' => 'get'));
echo $this->Form->input('username');
echo $this->Form->input('created');
echo $this->Form->input('group_id');
echo $this->Form->end('Search');
 
echo $this->Paginator->numbers(array('modulus' => 10));

Formヘルパーのcreateメソッドには、typeとして ‘get’ を指定することをおすすめします。もし指定しなかった場合は（Prgコンポーネントに倣って）自動的にGET用URLを生成してリダイレクトされます。

7月3日に福岡で開催されたCakePHP勉強会で、『MarkupHelperの紹介および PHPによるDSL実装の可能性について』という題で発表を行いました。以下に資料をアップロードしておきます（右キーで進む、左キーで戻る、上キーでサムネイル表示切り替え）。

資料へのリンク

※Studio ODIN – 高橋メソッド風 プレゼンスクリプトを使用しています。発表本番では改造版を使ったのですが、ライセンスが不明なので本家のスクリプトに直接リンクを貼っています。

githubのMarkupHelperリポジトリはこちら：
http://github.com/tkyk/cakephp-markup-helper

補足

質疑応答より。多少内容を変更しています。

Q. デザイナーに触ってもらうのは難しいのではないか？

A. このヘルパーはもともと「プログラマーがHTMLを書くのを楽にしよう」というコンセプトで作られているため、デザイナーとの連携が必要になる場面では使用できない・使用すべきでないと言えます。（デザインが比較的どうでもいい）内部向けの管理画面、ごく小さなelement、HTMLを生成する別のヘルパーの中、などで使用するのに向いています。

別の言い方をするとコードの分量が HTML > PHP の場合には使う意味は薄いです。コードの分量が PHP >= HTML の場合に威力を発揮します。

Q. XHTML以外のマークアップ言語を作ることはできるか？

A. MarkupHelperは「正しいXHTMLのタグか否か」をチェックしていないので、基本的にはどんなマークアップでも作ることができるはずです。ただし「そのタグが閉じタグを持つか否か」という情報を $emptyElements プロパティ（public）で管理しているので、必要に応じて再定義する必要があります。

Q. ループや条件分岐をメソッドチェーンに組み込めるか？

A.PHP言語の機能的な制約により、不可能です（PHP5.3のクロージャを使えば一応はできるかもしれませんが、書式が煩雑なのでDSLとしては実装できないでしょう）。

ループや条件分岐に相当する処理を入れつつメソッドチェーンを切りたくない場合は、その部分の処理を別のヘルパーのメソッドにまとめて連結することをおすすめします。
$markup->ul->MyHelper_loop_li($arr)->end;

……

勉強会で発表するのが初めてだったので緊張してしまい、発表中は聞いている人の反応を見ている余裕がありませんでした。早口に一気にまくしたててしまったような気がして、理解してもらえたかどうか不安だったのですが、あとで感想を聞くとそれなりに好評だったようでほっとしました。それから高橋メソッドによる大きな文字は、Ustream経由でも見やすかったようです。

勉強会の進行は（いくつか想定外の事態があったにも関わらず）大変スムーズで、気持ちよく発表できました。@k1LoWさんはじめ株式会社Fusicの皆さん、素晴らしい時間をありがとうございました。

福岡は魚もお酒も美味しくて、2次会以降ついつい飲み過ぎてしまいました。酔った勢いで、特に3次会ではずいぶん大口を叩いてしまったような記憶があります…。酔っぱらいの戯言が戯言でなくなるように、もっと精進していこうと思います。

会場で配られたマシュマロ

5月29日の『第5回CakePHP勉強会』に参加してきました。

京都から東京まで移動するため、今回初めて夜行バスを使ったのですが……失敗でした。想像以上に揺れがひどくて椅子が堅くて、ほとんど眠れなかったのです。おまけに東京はあまり天気がよくなくて、汗だくになったかと思うと寒くて震えるというような気温の変化が連続して、勉強会会場にたどり着いたときには既に満身創痍という有様でした。

そんなこんなで、プレゼンのたび電気が消されるたびに意識が飛びそうになるのを懸命に堪えつつ、きっちり懇親会まで参加してきました。その感想です。

技術ネタ

全部は書ききれないので、私がコメントできそうなものを選んで感想を書いています。プログラムの全体はEvent Entry::第5回CakePHP勉強会@TokyoおよびMASA-Pさんのブログ記事をご覧ください。

CakePHP1.3の概要 市川さん(@cakephper)

betaのころから1.3を使っていたので、発表中いくつかの機能については「そういえばこれは1.3の新機能だったな」と妙な感慨を持って聞いていました。それだけ1.3の新機能は利便性が高く、一度使えば当たり前になるということです。

一方で、それら新機能の実践的なノウハウについてはまだまだこれから発見・共有されていく段階だな、とも感じました。例えば当日 #cakephpstudy のTLでは「libsとverndorsの使い分けはどうするの？」という疑問が流れていましたし、スライド中routeClassの例として『Using custom Route classes in CakePHP』から転載されたコードは、直接Modelをnewしているためにテスタビリティに難があります。そうしたノウハウはいずれこのブログなどでもまとめていければと思います。

Ktai Library on CakePHP1.3 滝下さん(@ecworks_masap)

幸か不幸かまだ本格的な携帯サイトを作った事はないのですが、将来作るとなったらほぼ間違いなくお世話になるであろうライブラリなので、興味深く聞くことができました。最新版ではktai-devという形でライブラリ統合済のCakeコアも配布しているとのことで、もはや一ライブラリというよりも「CakePHPをベースとした用途特化型フレームワーク」に近づきつつあると言えそうです。それすなわち、CakePHP 1.xの成熟度が一定のレベルに達した証左だと言えるかもしれません。

ただそうして「ライブラリ」がカバーする範囲が大きくなればなるほど、ソフトウェアとしての Responsibility も大きくなります。その点については懇親会で直接お話しさせていただく機会があったのですが、やはり既存のライブラリ・サービスとの兼ね合いや、本来キャリアが提供すべき情報をどこまでサポートすべきかといった点について苦労されているようでした。

コアライブラリのエレガントなハック 清水紘己さん(@hiromi2424)

「Cakeコアの構成要素をいかにエレガントに置き換えるか」という、なかなか聞く人を選ぶ話題でした。個人的には大好物です。特にコンポーネント初期化処理をハックする苦労を味わった同士として、懇親会では固い握手を交わさせていただきました。

CakePHP2.0の概要を見たときに「エイリアス」というのがイマイチ何なのかピンと来なかったのですが、この発表を聞いていてよく理解できました。静的型付言語でいうと置き換えられる「名前」がインターフェイスを規定し、置き換えるクラスが実装クラスという事になります。依存関係が生ずる対象がクラスではなく「名前」なので、コア内部の依存関係であっても後から置き換える事が可能になります。

「CakePHPでjQueryを使ってみた(仮)」 – @nano_eightさん

CakePHPでjQueryを使うなら下手にHelperなど使うよりも直接JavaScriptを書いた方が早い……と考えていたので、flashとelementの組み合わせ+SCRIPTタグべた書きという手法は目から鱗でした。Cake/PHP, JavaScriptそれぞれを分けて考えるのではなく、トータルで最も効率の良い方法をこそ考えていくべきなんだな、と認識を改めました。

「WordPressの管理画面のプラグインにCakePHPを使う」- 原さん(@kara_d)

「あのCMS eZ publishをCakePHPのModelにしちゃう」- @leebennyさん

他のPHP製ソフトウェアとCakePHPを組み合わせて使用する、というアイデアは多くの人が検討したことがあるだろうと思います（私もあります）。@kara_dさんのWordPressプラグインではDispatcherを無効にしたindex.phpを読み込むという大胆な手法で、@leebennyさんのeZ publishではDataSourceを実装するという正攻法で、これを実現されていました。いずれも他のソフトウェアに応用可能な方法だろうと思います。またCakeとは直接関係ありませんが、eZ publishの概略について学べたのも良かったです。

会場・コミュニティの雰囲気など

発表の様子は常時Ustreamで配信され、全国各地のサテライト会場に中継がつながっており、海外からの発表がSkype経由で行われ、会場では記念ロゴ入りのマシュマロが配られ……「コミュニティーベースの勉強会でここまでのことができるようになったのか！」と感嘆せずにはいられませんでした。

この種の勉強会に参加するのが初めてということもあり、正直なところ、ちょっと距離感を掴むのに戸惑ったというのも事実です。ただ懇親会で近くで飲んでいた@nano_eightさんのところに「プレゼン良かったですよ！」と多くの人が集まるのを見て「うらやましいなー」と思ったのもまた事実で、次の機会にはぜひ発表者として参加しよう！と思いました（実は今回もLTのお誘いは受けていたのですが、忙しさと不慣れを理由に断っていたのです）。

……

東京散策ではiPhoneが超役に立ちました。慣れない都市で迷わずに動き回るコツは「自分の勘を一切信用しないこと」なのです。午前中は国立新美術館で開催中の「オルセー美術館展」を堪能しました。モネの『ロンドン国会議事堂、霧の中に差す陽光』とゴッホの『星降る夜』には魂が震えました。もう一回見に行きたいくらいです。久しぶりに歩き回った東京は広々としていました。京都と比べればほとんどどんな土地も広々と感じるのですが、東京も例に漏れず、ずいぶんと空間に余裕があるなあ、と思いました。

環境: CakePHP1.3

ComponentTestCaseを使ってメールの送信をテストする方法をまとめておきます。Qdmailerを使うことを前提としていますが、標準のEmailComponentなど他のコンポーネントでも同じようにテストできると思います。

単純なケース

メール送信をテストする上で最も重要なことは、メールの種類ごとにコンポーネントを作るということです。

まずメール送信コンポーネントに共通の振る舞いを定義するため、以下のような Mailer クラスを app/libs に作ります。 実際のインターフェイスや初期化処理などは自分のアプリケーションに合わせて調整してください。

abstract class Mailer extends Object
{   
  var $components = array('Qdmailer.Qdmailer');
  var $_controller;
  var $_settings;
 
  function initialize($controller, $settings=array()) {
    $this->_controller = $controller;
    $this->_settings = $settings;
  }
 
  function create() {
  }
 
  protected function _rawSend() {
    $this->Qdmailer->send();
  }
 
  function send() {
    $this->Qdmailer->resetHeaderBody();
    $args = func_get_args();
    $this->dispatchMethod('create', $args);
    $this->_rawSend();
  }
}

次にメールの種類に合わせたメール送信用コンポーネントを作ります （他のコンポーネントとの混在を防ぐために components/mailers などサブディレクトリに作成することをおすすめします）。

先ほど作った Mailer クラスを継承して create メソッドを実装します。 メールの送信に使用する値は、create の引数で受け渡すよりは、 コントローラの viewVars 経由で受け取る方が良いと思います（メールテンプレートのレンダリングでも必要になるので）。

App::import('Lib', 'Mailer');
 
class RegisterRequestMailerComponent extends Mailer
{
  function create() {
    $email = $this->_controller->viewVars['User']['email'];
 
    $q = $this->Qdmailer;
    $q->resetHeaderBody();
    $q->to($email);
    $q->subject('ユーザー登録が完了しました');
    $q->cakeText('', 'register');
  }
}

単体テストではこの create メソッドをテストします（Mailerクラスに対するテストも書く必要がありますが省略）。 特定の入力（引数、viewVars）に対して宛先、送信元、そして本文などが期待通りに作成できるかどうかをテストします。

class RegisterMailerComponentTest extends ComponentTestCase
{
  var $components = array('RegisterMailer');
 
  function testCreate() {
    //viewVarsの登録
    $data = array('User' =>
                  array('id' => 123,
                        'username' => 'xxxxxx',
                        'email' => 'abc@example.com'),
                  'login_url' => 'http://example.com/register');
    $this->Controller->set($data);
 
    $this->RegisterMailer->create();
    $q = $this->RegisterMailer->Qdmailer;
 
    //本文
    $body = mb_convert_encoding($q->content['TEXT']['CONTENT'],
                                'utf-8', $q->charset_content);
    $this->assertTrue(strpos($body, $data['login_url']) !== false);
 
    //宛先など
    $this->assertEqual(1, count($q->to));
    $this->assertEqual($data['User']['email'], $q->to[0]['mail']);
  }
}

このコンポーネントを使用するコントローラからは、send メソッドを呼ぶだけです。

class UsersController extends AppController
{
  var $components = array('RegisterMailer');
 
  function finish() {
    //...
    if($this->User->save()) {
      $this->RegisterMailer->send();
    }
  }
}

より複雑なケース

次に一度に複数のメールを送る場合について考えてみます。 例えば登録完了メールをユーザと管理者に送るとしましょう。 この場合は「ユーザ宛メール（UserRegisterMailer）」と「管理者宛メール（AdminRegisterMailer）」の他に、 それらをまとめる「RegisterMailer」という3つの Mailer クラスを作成します。

UserRegisterMailer と AdminRegisterMailer は単純な例と同じように作ってテストしてください。 RegisterMailer では $components 配列を使ってそれら2つを読み込み、送信処理を委譲します。

App::import('Lib', 'Mailer');
 
class RegisterMailerComponent extends Mailer
{
  var $components = array('UserRegisterMailer',
                          'AdminRegisterMailer');
 
  function sendUserMail() {
    //viewVarsの加工処理など...
    $this->UserRegisterMailer->send();
  }
 
  function sendUserMail() {
    //viewVarsの加工処理など...
    $this->AdminRegisterMailer->send();
  }
 
  function send() {
    $this->sendUserMail();
    $this->sendAdminMail();
  }
}

このクラスに対するテストはモックを使って行うことができます。 本文や宛先の生成処理は移譲先でテストされているので、 移譲先に対する入力の形式と、適切なメソッドの呼び出しが行われていることをテストすれば十分です。

App::import('Component', 'UserRegisterMailer');
App::import('Component', 'AdminRegisterMailer');
Mock::generate('UserRegisterMailerComponent');
Mock::generate('AdminRegisterMailerComponent');
 
class RegisterMailerComponentTest extends ComponentTestCase
{   
    var $components = array('RegisterMailer');
 
  function startTest($m) {
    parent::startTest($m);
 
    $this->RegisterMailer->UserRegisterMailer
	  = new MockUserRegisterMailerComponent();
 
    $this->RegisterMailer->AdminRegisterMailer
	  = new MockAdminRegisterMailerComponent();
  }
 
  function testSendUserMail() {
    $this->Controller->set(array(/* ... */));
 
    $this->RegisterMailer->UserRegisterMailer->expectOnce('send');
    $this->RegisterMailer->sendUserMail();
    //...$this->Controller->viewVars が適切に加工されていることなどを確認...
  }
 
  function testSend() {
    $this->RegisterMailer->UserRegisterMailer->expectOnce('send');
    $this->RegisterMailer->AdminRegisterMailer->expectOnce('send');
    $this->RegisterMailer->send();
  }
}

このコンポーネントの使い方は「単純な場合」と全く同じで、コントローラは一切変更する必要がありません。