おどおどしつつCatalystをモバイルサイト開発に導入してみた：主要モジュール習得編

今回は、開発に際し、基礎知識として必要となった主要モジュールについて、習得していった経緯を書いてみます。

まずは、なんといってもモデルの基本となるO/Rマッパー、DBIx::Classおよび連携部分を理解を進めました。

DBIx::Classはこれ自体が巨大な機構なので、理解もひと苦労なのですが、まずは何はともあれ、「今日のCPANモジュール」の「use DBIx::Class」を読んで雰囲気を掴むと分かりやすいです。

とはいえ、このコンテンツはあくまでイントロレベルなので、実用にはやっぱり一次情報をよく読むのが結局近道だと思います。

まずはDBIx::Classのマニュアルイントロがなんといっても分かりやすいです。

ここできっちりResultSourceやらResultSetやらの考え方を理解しておくと、各関数がどういう考えで設計されているのか、ひいてはDBIx::Classのポリシーが理解しやすいので利用の幅も広がっていくと思います。

DBIx::Classのwhere句の指定は独特なところがあるのですが、これはSQL::Abstractを踏襲しているので、こちらのモジュールのドキュメントにも目を通しておいた方が良さそうです。

特に、WHERE句のくだりは、ちゃんと読んでおくのと読まずに進むのとで理解度に非常に差がつくと思います。個人的には、かなり目から鱗が落ちました・・

RailsのActiveRecordよろしく、リレーションの記述についてもよく読んでおいた方が良いです。

個人的には、belongs_toの外部キーの書き方を理解してちゃんと使うのに非常に苦労しました…Railsとはやっぱり根本的な思想に若干の違いがあるように思います。

お次は定番Template-Toolkit。こちらもまずは概要を掴むのに「今日のCPANモジュール」の記事を読みました。

一次情報としては、当初は本体のpodだけざっと目を通しておけばまずは十分ではないでしょうか。マニュアルイントロやチュートリアルも付いていますが、テンプレートエンジンを使ったことがあれば、非常に理解しやすいので、詳細は使用に応じて辿っていけばすんなり導入できると思います。

従来使用していたHTML::Templateと比較すると、特にオブジェクトが簡単な構文で呼び出せるのが非常に気に入りました。

例えば、テンプレートの任意の箇所で、GoogleAdsenseの広告を埋め込めるようにしたい場合*1には、

<TMPL_VAR name=google_adsense>

と埋められるようにしたら、コントローラーの共通処理部分で、GoogleAdsenseをHTTPで取得して、変数に格納しておく、という部分を実装する必要があります。

となると、「埋めない」場合でも、HTTP通信が発生することになり、ムダが生じます。
query()メソッドを使用すれば、

if ($template->query(name => 'google_adsense')) {
    $template->param(google_adsense => $adsense->get());
}

などとすれば「テンプレートに'google_adsense'が埋まっているときだけ」HTTP通信をして広告を取得してくるようにもできますが、他にも同様な変数があればソースコードが煩雑になりがちです。第一、コントローラーに全部記述されている必要があるというのがイケてない。

Templateであれば、オブジェクトのメソッドを呼び出せるので、例えばadvというオブジェクトインスタンスが、googleというメソッドで広告を取得してきて出力するように実装さえしておけば、

[% adv.google %]

と記述した箇所があればそこで初めて広告を取得して出力してもらえるし、可読性や独立性の面でもかなりスッキリします。

他にも独自の構文（WRAPPERがイイ！）や設定の柔軟性もさることながら、豊富なプラグインやフィルタなどの存在やそれ自身の開発の容易性もかなり魅力的だと思いました。まあ、このあたりは今さら言及することでもないと思いますが・・

バリデータの利用についてもちょっと悩んでいたんだけど、Perlだと、Data::FormValidatorか、FormValidator::Simpleがスタンダードということを知りました。（今頃ですが）いずれもCatalystのプラグイン化されているけど、諸事情によりFormValidator::Simpleを「プラグインでないまま」利用することにしました。

一次情報は本体のpodしかないですが、とても分かりやすい。

バリデータの静的な設定はYAMLから読め、DBIC::Uniqueなどの設定でのResultsetを与えるなど動的な部分はクロージャーで差し込めるような、いわば一階層ラップするようなモジュールを作成し、使用しています。

メール送受信については、これまでMail-ToolsとMIME-toolsを利用していました。いずれもRatingも高くて使い勝手も悪くなかったのですが、Catalystに

というモジュールを発見。これはEmail::MIME::Creatorをベースにしているようで、他にも、Perl5 今昔でも、Email::Sendが推奨されていました。

Email::MIME::Creatorのドキュメントを軽く読んでみると、

PERL EMAIL PROJECT
This module is maintained by the Perl Email Project.
http://emailproject.perl.org/wiki/Email::MIME::Creator

などという一節が。PERL EMAIL PROJECTなるものがあることを知り、今後こちらに移っていくようなことを発見。そこで今回いっそのこと乗り換えてみることにしてみました。

といっても、モバイルだと空メール受付→メール返信など、Web以外でのメール送信が多用されたり、Catalystに依存しすぎるのは避けたかったので、Catalyst::View::Emailは使わず、直接モジュールを利用するもしくは簡単にラップするライブラリのみ作成してみることにしました。

また、mediawikiの方より、個別のPODを読んでいった方が、特にSYNOPSISなどは分かりやすいようです。

ただし！モバイルで主流のMail::Address::MobileJpなどは、MailTools系のMail::Addressのサブクラスのようで、結局はPEP系で統一するのは難しそうですね。まだまだ過渡期なのかしら。

ふー、やっとここまでまとめられました。なかなか時間がかかります。

次回はもう一度Catalystを見返して、開発に必要なプラグインや諸知識について、習得していった経緯について書いていきたいと思っています。更新頻度は低いですが・・

ていうかまだまだモバイルが関係ない。。

*1:PCサイトの場合はJavaScriptですが、モバイルの場合は、都度HTTP通信でバックエンドで取得する必要がある