こんにちわ。http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=WebDesktopServer では戻るボタンを全否定しました(^^;。しかも非Ajaxで。<br><br>アプリは"一般的には"戻れるとは限らないし、戻る機能を提供するか否かをアプリの性質ごとに細かく仕分けるのはバッドノウハウくせぇという気がしてるし、Webアプリ"だから"戻れるようにすべきっていう議論は変だと思うし。Webアプリ以外で戻るボタンっていう話はロクに聞かない(くらいに実は需要が無い！んじゃないか？)と。(なんでVT100やXFree86には戻るボタンが無いのか考えてもみろよと…)<br><br>戻るボタンが使えりゃそりゃ一見便利なんですが、無茶ゆーな！っていう気がしてます。むしろ逆に戻るボタンからの脱却はWebアプリがアプリとしての一級市民になるための通過点なんじゃないか？とすら思っています。<br><br>というか、どっちかというとTimemachineComputingの実装を先にする(それに依存するかたちで実装する)のがいいんじゃないかと…。

でも"普通のアプリ"にはUndoがありますからねえ。いきなりUndo無しの世界は辛いです。

でも逆にあらゆるアプリに画一的なやり方(実装形態)でUNOOを付けるってのも無茶だと思っています＞戻るボタン<br>また、「COMMITやROLLBACKの前に戻れることに意味はあるか？」ってのも問題だし。<br><br>UNDOがどう実装されるか？は、そのアプリごとのMODEL次第、ということにするのがいいんじゃないかと思っています。<br>WDSでもアプリ(MODEL)がUNDO機能やUNDOボタンを提供することを否定しているわけではないです(^^;<br><br>あ。あと同じような話として、URLとアプリの状態が一対一対応するってのも、夢物語だよなあと思ってます。WDSではそれも否定しています。アプリごとにURLは1つ。URLはアプリの画面の最新状態の投影に過ぎないという捉え方。

TimemachineComputingというかSubversionみたいな世界観をきちんと持ち込めば解決はするかな、とは思わないでもないです。<br><br>サーバと一回通信するごとにオブジェクト(GUIにせよMODELにせよ)のTREEをリポジトリにCOMMITするみたいなイメージ。TREE全体に対してRevision番号を与え、それはクライアント(SubversionならWorkingDir、Webならブラウザの隠しField)にも教える。以前と変化してない部分はCopyOnWriteで圧縮。<br>戻るボタンで戻ったときはRevision番号に基づいてTREEの何処に戻ったかを特定する。そこから行った操作はRevisionの分岐で表現する。<br>DBのCOMMITなど後戻りできない処理を行ったら、古いRevisionをリポジトリから破棄して(つまり戻るべきBASE Nodeを存在しなくして)戻れなくする。<br><br>…なんかメモリ馬鹿食いしそうです(^^;<br>あとAjaxみたいに通信単位が細分化したらお手上げ？<br><br>あとRevision番号がURLに現れるといいのでしょうけど。うーん。POSTのときにはURLにパラメタつけれないから、hostname/app/revision みたいなURLにするといいのかな。revisionの省略値はHEAD？<br><br>こう(ここまで厳重に)すれば、状態が次々遷移する所謂普通のアプリと、URL参照透過性(^^;とが、共存できるぞってことになりますかね。

あと、コミュニケーションとしてのURLについては、その反例としての「個人情報に紐づいたデータや操作」ってのもありますね。俺の(Web)デスクトップの内容は必ずしも自分というContextから切り離したいわけじゃなく、むしろ恐らくは大抵の場合、他人にゃ見せたくないんで見せる手段なんかも不要、みたいな。

Webを受け入れることで，UIは一気に数年は退行しました。Web的なUIを受け入れるということは，そういう貧弱な環境も丸ごと受け入れるってことなんで，「戻る」だけを拒否するのは違うんじゃないかと思います。実装側の都合はそうであっても，UIってユーザのものですからね。