コラム

みなさんこんにちは。なんだか空気が異様に乾燥しまくりな昨今ですがいかがお過ごしでしょうか。 せっかくできたと思ってた立ちコロですが、ビデオ撮って見たら角度が全然甘い上に腰痛な感じでちっともやる気がでません。あーあ。

さて、今日はウェブの「フォーム」についてのおはなしです。 気持ち悪いjava.awtとかSwingが廃れてHTMLフォームが幅を利かせるようになったのは慶賀の至りですが よく考えるとHTMLフォームの仕様も結構気持ち悪いですよね。それはさておき。

ふつうのウェブアプリケーションとかだと、 「フォームを出力する存在」と「そのフォームにPOSTされてきたデータを受け取る存在」は 別になってることが多いと思います。でも。

そもそもあるプログラムが「こういうデータが欲しいんだよ。お前ちょっとクライアント(ブラウザ)に聞いてこいよ」 ってことでフォームを出力したのに、その回答を受け取るのが別プログラムってなんか効率悪いっていうか 「聞いたお前が自分で取りに行けよ」みたいな気がしませんか。

というわけでタイトルの「フォーム台帳」なんですが、これはどういう仕組みかというと、 オブジェクト指向でいうところのオブジェクト、つまりクラスのインスタンスが、 自身のメンバへの入力をブラウザ側から受け取りたいとき （例えばユーザ情報を扱うクラスがユーザデータつまり名前とかメールアドレスとかを入力させたいとき） オブジェクトが直接「入力フォーム」を発行し、それがフォーム台帳に登録され、 ブラウザからデータが返ってきたときにフォーム台帳が自動的にデータを仕分けて 「聞いたオブジェクト（つまり入力フォームを発行したオブジェクト）」のメンバに直接入力値をセットする という仕組みです。もう本当に意味わかんないですね。すみません。

なんかうまく書けないし段々書くの嫌になってきたんで、昔書いたスライド貼っておきますね。 2002年10月ってことは今から８年前に書いた奴ですね。進歩してないなあ。

というわけです。なるほどねえ。こうすると例えば表なんかも

となるわけですね。
ダメなフレームワークだと１行１行に入力フォームがあるような表の場合、同じクラスから各行を出力させると name要素がconflictしたりして困ったな、ってことになりがちなんですが、cgiosだと 各inputタグのname要素についてはネットワークで言うところのNAT的な名前の付替えをしているので 原理的にconflictが起きないようになっています。 あとアプリケーション側で聞いてもいない要素にデータを(CSRF的に) 投げ込まれることがない (NATによって外部から内部ローカルIPアドレスに直接通信できなくなるのと原理的に同じ)、というのも 精神衛生上とてもよいですね。

ではまた次回お会いしましょう。さようなら。