Catalyst::Manual::Aboutの個人的な要約
読みながらメモっただけなので超適当な日本語だと思います。読み返してもいないし。
Catalyst::Manual::About - The philosophy of Catalyst - metacpan.org
CatalystはWebアプリケーションフレームワーク。Webアプリケーションのタスクにはこんなものがある。
What is Catalyst?
- Webサーバーとやりとりする
- URIに基づいてなにかする
URIはアプリケーションが何をするかを指し示している。http://www.mysite.com/add_record.cgi?name=John&title=PresidentはJohnさんのPresidentってタイトルの本をデータベースに追加する。http://www.mysite.com/catalog/display/23は23番のアイテムを表示する。http://www.mysite.com/order_status/7582は注文番号7582のステータスを表示する。http://www.mysite.com/add_comment/?page=8は8ページ目にコメントを追加するって具合に。
- データストアとやりとりする
きっと情報を取っておくためにデータベースを使うでしょう。アプリケーションはデータベースとやりとりしてデータを作成したり編集したり削除したりする必要があります。
- フォームを扱う
ユーザーがフォームを送信したらそれを受け取って内容が正しいか調べてからなにかすることになるでしょう。注文をサブミットしたり、レコードを更新したり、メールを送ったり。エラーが発生したらそれをお知らせしないと行けません。
- ユーザーを管理する
普通のユーザーや管理ユーザーなど。権限分け。普通のユーザーは見れるだけで編集は出来ないとか。ユーザーが許可したことだけ出来るようにしないと行けない。
- アプリケーションを作る
ログを追ったり、テストをしたり。新たな変更が既存のコードを壊さないようにしないと行けない。
Catalystはこのようなことを簡単にできるようにします。いろんなプラグインもあるし。
- Webサーバーとやりとりする
どれを使ってもおk。テスト用のWebサーバーも付いてるお。
- URIに基づいてなにかする
すげー便利にできる仕組みがあるお。
- データストアとやりとりする
いろんなデータベースとやり取りする多くのプラグインがあります。データベースじゃないストレージ用のプラグインもあります。
- フォームを扱う
フォーム作成とバリデーションのためのプラグインがあります。
- ユーザーを管理する
セッション、認証、権限分けのためのプラグインがあります。
- アプリケーションを作る
詳細なログ出力が組み込まれてます。新しいテストの作成を手助けします。
昔のWebプログラミング
Content-typeをprintしたりクエリストリングをsplitしたりしてた。
これよりもCGIモジュールを使った方がいい。このモジュールはすごい革新的でいまでもまだ広く使われてる。でもおっきなアプリケーションには向かない。たいていはロジックと表示のためのコードが分離されてないし。複雑な制御フローだと大変。
CGI::Applicationはモジュール化をすすめた。簡単でわかりやすい制御フローだし、プラグインも使える。AxKitってのもある。Maypoleもある(Catalystがベースとしたもの)。JiftyはWEbサイトを作るのをすげー自動化してる。Rubyで書かれたRuby on Railsはすごい人気ある。
まあこんなこと書くのはこの文書の目的じゃない。
MVCパターン
アプリケーションフローを扱うのがControl(C)
情報を処理するのがModel(M)
結果を出力するのがView(V)
これらを分離する。それぞれ影響を与えないようにすると単体で入れ替えできる。
MVCに関してはいろいろと議論されてるけどそんなことには興味ない。Catalystではどこにどのコードを書くか強制したりしない。ただ私たちがうまく行くと考えてることを提案するだけ。
CatalystではMVCはさまざまなPerlモジュールとして作られます。
Modelの目的はデータへのアクセスと変更。たいていはデータベースとやりとりするけど、それいがいでもおk。
Viewの目的はデータをユーザーに対して表現すること。たいていはHTMLを作成するテンプレートシステムを使う。Template ToolkitとかMasonとかHTML::Templateとか。でもPDFを出力したりメールを送ったりもできる。CatalystアプリケーションではViewはたいてい小さいモジュールになる。ただ単に他のモジュールとの橋渡し役となる。表示ロジックはテンプレート自身に書かれる。
ControllerはCatalyst自身のこと。リクエストが来たらコントローラモジュールの1つで受ける。このモジュールはユーザーがしたいことを理解して、Modelから必要なデータを持ってきてViewに渡す。
簡単な例
一般的な考え方として、あなたはアプリケーションの他のところに影響を及ぼさないように物事をうまいことできるべきだ。簡単な例を見てみる（やりかたはいっぱいあるってことを忘れないこと。これはその一例）。あなたは表示するレコードを持ってるとしよう。図書館の本でも音楽CDでもなんでもいい。カタログの一つがある。ユーザーはこんなURLを与えられる。http://www.mysite.com/catalog/display/2782
さーどうする？
まず、Catalystはあなたが"catalog"ってコントローラを使ってると理解する（CatalystがURLをどう解釈するかはあなた次第。URLディスパッチはすげー柔軟にできる）。それから、そのコントローラのdisplayっていうメソッドだって決める。このプロセスのどっかで認証や権限分け処理をして、ユーザーが登録してるか、レコードを表示できるかチェックすることも可能。で、コントローラのdisplayメソッドは2782ってレコードが欲しいんだってわかるから、Modelにレコードを問い合わせる。レコードがないって返答が来たらViewにエラーメッセージを表示するように言うし、そうじゃなかったらそれを表示するように言う。どちらの場合でもViewはHTMLを生成する。で、Catalystはユーザーのブラウザにそれを送るお。サーバーはなんでもいい。
これがどうあなたの手助けになるだろうか？
多くの場合。あなたは小さなカタログを持ってて、SQLiteみたいな軽量のデータベースを使ってるけど。そのうちMySQLとかPostgresとか、ひょっとしたらOracleとかDB2とかにするかもしれないけど、そのときはModelだけ変えればいい。
Viewはどうだろうか？
表示に関してはほとんどすべてテンプレートがやるって考えると、それをコードを書かないデザイナにまかせちゃうことが可能だ。あなたがコントローラでデータをかき集めたらそれをViewに渡せばあとはViewの責任だ。出力を変えたかったら新しいViewを書けばいい。
その他必要なことはCatalystがやる（たとえばURLから2782を取り出したり）。または簡単にプラグインできる（認証とかViewにTemplate-Toolkitを使ったりとか）。
で、Catalystはなにも強制しない。Template-Toolkitはとても強力なテンプレートシステムで、データベースに接続して、クエリを発行して、それらをTTベースのビューからやることもできる（まじで？）。あなたがやりたいなら。ページングもできるし（ControllerかModelでやる）。さっきの例だとコントローラがクエリの結果を見てViewにエラーメッセージを出すか、結果を出すか決めたけど、直接Viewで決めることも出来る。みんなあなた次第で、Catalystは何も強制しない。
ある場合には、個人的な好みよりも、物事をある決まった方法でやるほうがいいこともある。テンプレートからデータベースに問い合わせるのは関心の分離の原則を壊すし、きっとデザイナを狂わせる原因になるし。また、結果がない場合に何を表示するか決めるのはコントローラよりはテンプレートのほうがいいだろう。
Catalystはただツールを提供するだけ。
