Seasideの懸念点
clean URL
SeasideはURLが変態なんだよな… clean URLのルーティングはプログラミングすべきではなくて簡潔に宣言的DSLで設定したいもんだ。
Seasideの継続(continuation)は、「アプリとしてのウェブページ」でのみ使えば良くて、「ドキュメントとしてのウェブページ」では使わないほうがいいということだな。それらの混在についてはまだ考えてない。
security: session hijacking
SeasideのURLってセッションハイジャックしやすいので、製品で使う気がしないんだよね。ウェブのアーキテクチャのREST原則に反してる気もするんだよな。
「ウェブアプリケーション」(アプリとしてのウェブページ)ならば、ログインセッションはHTTPSでクッキー、継続はURLパラメーターにするといったところか。継続キーを盗んでもセッションキーが盗めなければ安全なので。
solution?
URL routing DSLを追加してclean URLをレイアウトして、continuation使わない。これやらないとSeasideがインダストリーレベルのウェブサービスにならないと思うけど、そうなるとSeaside使う意味ほとんどない気が。
そんなこともないか。コンポーネントベースのアーキテクチャはよいと思う。でもcontinuationは要らない。ライトウェイトなコンポーネントベースのフレームワークがあれば使ってみたい。
@zerobase04 SeasideRestなんてのもありますが、最初からRESTを指向したものであればAIDA/Webもいいかもしれません code.google.com/p/seaside/wiki… aidaweb.si/restfull%20app…
— Masashi UMEZAWAさん (@umejava) 2013年2月13日