日常
Webアプリ。
困っているが、問題が何なのかがよく分からない。
Railsとかいうやつを使えば全てうまく行くのだろうか？
Seasideとかいうやつを使えば全てうまく行くのだろうか？
モデルとモデルに関するルール
以前は何かを作ろうと考えたとき、真っ先にクラスの構造と関連を考えてた。
最近は真っ先にテーブルの構造と関連を考えてしまう。
あるアプリケーションを作ることを考える。
ここで言うアプリケーションとは、一つの対話処理というような意味だ。
アプリケーションは欲しいデータモデルに対して、適切な値が設定される。
例えばユーザーを新規作成するWebフォームはアプリケーションであり、
例えば、名前の欄に半角カナが含まれていないこや
ユーザー権限テーブルにない権限がセットされようとしていないことを保証する。
アプリケーションとは、要するに、
値の範囲と値同士の整合性を保証するものだと思う。
そのような値の保証とは、
・〜という権限のユーザーは〜という状態にあるとき、〜というデータを〜という値にすることができる/できない。
・〜という権限のユーザーが〜という状態にあるとき、〜というデータを〜という値にしたなら、関連して〜というデータを〜という値に変更しなくてはならない。
という宣言の塊でしかないように思う。
本当はそうではないのかもしれないが、
私はそのような宣言の塊として仕様を意識する。
宣言の集合、状態の遷移、これらを具現化する手法として、
条件分岐や繰り返しを記述してゆくというのは間違っているように思う。
宣言とか状態遷移とか、そういうアプローチのフレームワークって知らない？
って隣の人に聞いたらニヤっとされたけど、
やっぱり無いんでしょうか？
というか、一体全体それが無いというのはどういうことなんでしょうか？
何故無いんでしょうか？
ビュー
モデルの状態をどう示すか、これにはそんなに困っていない。
HTMLとかのテンプレートというのは、
所詮はHTMLっぽい文法で書いたビュー(しかも単なる関数)でしかない。
セッション
HTTPそのものが持つ制約ではないにしろ、多くの場合、通信単位がぶつ切りにされ、それに伴ってプログラムの実行単位もぶつ切りにされる。
アプリケーションサーバーとして作るならその制約からは解放されるんだけど。
セッションは特定の実行単位のモデルをどう保存・復元するかの問題。
別に普通のフレームワークの手法でそんなに困ってはいない気はしているけど、
Seasideのように継続を使えば自由度(と難易度)は確かに高まるとは思う。
ログラムの構造
あるURLにアクセスするとあるクラスのあるメソッドがコールされる、程度では困るが、
それでも、それなりに設計すればそれなりに解決する気はしている。
これについてSeasideは確かに優れているのかもしれないと改めて思った。
