アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
エラーメッセージ(オフトピ) (スコア:1)
Re:エラーメッセージ(オフトピ) (スコア:0)
これだけ見ると、ノウハウとかオープンソースとかと無縁な気が…
gaucheとかapacheぐらい?
/.Jの人に聞きたいのだけど、SchemeでCGI組んでるのを初めて見た気がするのだけど、実際は多いのでしょうか?
Re:エラーメッセージ(オフトピ) (スコア:1)
kahua本家 [kahua.org](なんで誰もリンクしてないんだ?)にあるように、
継続ベースのwebアプリなフレームワークってことで、
GUI Widgetプログラミングでいうところの「Modal Window(いわゆるDialog)」と「Modeless Window」
みたいなものを、素直に記述できるっていうことらしい。
ModalとかModelessとかの挙動が楽に使い分けられるのって、
Webアプリみたいに「なにがなんでも画面遷移せざるを得ない」環境では重宝するはずですよ。
Modal窓を作るのを「放棄」するという逃げは可能だが、それはあくまで逃げ。
だってさ、画面遷
Re:エラーメッセージ(オフトピ) (スコア:0)
「普通の奴らの上を行け」は私もときどき読んでいます。
>○表示画面の世代を自動管理するので、「戻る」や「Reload」などのWebブラウザのヤンチャな挙動にも一切惑わされない。
履歴をサーバ側で保存するのはわかるのですが、ブラウザからの挙動にたいしてどのように応答すれば正しい安全な動作
Re:エラーメッセージ(オフトピ) (スコア:1)
LLW2004もコミケも踏み越えて。(というか忙しかったりして、これ書ける状態じゃなかったんで。)
>履歴をサーバ側で保存するのはわかるのですが、ブラウザからの挙動にたいしてどのように応答すれば正しい安全な動作になるのかは、
>どのようにして決めるのでしょうか。
kahuaがどうしてるのかは、見てないので知らないm(__)mので、俺の話を話半分に聞いておいてください。
#てゆーかkahuaとかRubyのDivとかJSFとかEchoWebFrameworkとかがどうしてるかを見るのが先決かもですが。
#swt.sourceforge.netはどうだったかなあ…
まず画面のバージョンという概念を持ち込む。
「全ての」表示機会には、(そのセッションの中で)一期一会なバージョン番号がある、とする。
同じ番号は(1つのセッションの中では)二度と出てこないものとする。
たとえリロードであっても、前回と今回とでは違う番号である、とする。
#なので、キャッシュなんかしたら、偉い事になりそうですが(^^;
そして、その画面から(ブラウザによって)発せられるリクエストには、
必ずそのバージョン番号がつくように細工する。
アンカーやボタンをそう言う風に作る。
俺風にいえば、最初からそういう機能を持っているようなWidgetを(ライブラリ作者が)作っておけばいい。
そうすればライブラリユーザはそのWidgetオブジェクトをnewするだけ。
#余談ですが、そうやって整理していくと、アンカーWidgetには「ユーザが設定すべきパラメータ値」が一切無くなってしまいました。
#サーバに伝わるのは、「どのアンカーWidgetがClickされたか」というObjectID値だけ。そしてIDはライブラリが自動的に設定するので、
#ユーザプログラムは何もすることがない。
一方で、セッションのほうも、自分(セッション自身)が「最後に」出した画面のバージョン番号を、覚えておく。
そして、リクエストが来た時、セッションは、そのリクエストにくっついてるバージョン番号と、
自分が最後に出したハズの画面のバージョン番号とを、照合する。
ここで、戻るボタンやリロードボタンを使うと、バージョン番号は「ずれて」るはずです。
あるいは何処かとんでもない所から来たバージョン番号なしのリクエストなら、ずれてるどころの騒ぎじゃないぞ、と。(番号がNULLです)。
ココから先は話にバリエーションが出てくるはずです。
俺の奴 [nifty.com]では単純に、無視する戦略を採っています。
つまり、リクエストが最新のバージョン番号を持っていなければ、画面の再描画の要求だとしか見なさず、
リクエストの中のその他のパラメータは全部無視するようにしています。
パラメータは、どのボタンやアンカーが押されたか?のObjectIDなどを持っているんですが、これらを無視します。
つまり、ボタンが押されて何らかのアクションが期待されてるぞ、という事実自体を、揉み消します(^^;
サーバのメモリに有るWidgetに(ひいてはそれに繋がってるAction Closureに)イベントを伝達しません。
そしてデフォルトの動作をします。つまり、前回表示したときと同じ(状態の変化してない)一群のWindowを、
単純に再びHTMLとしてレンダリングして送信するだけ。
妥当かと言われれば意見が分かれると思います。
俺は、(継続を使わない限り)うまくやれそうにないので、
うまくやれないくらいだったら悲観的に無視するぞという、後ろ向きの選択をしたわけです。
不便かな…
いっぽう、継続云々なサーバだと、俺のみたいに最新バージョン以外は無視という戦略じゃなく、
古いバージョンの継続(プログラム状態)も記憶していて、それらとも照合するように振舞うのだと思います。
そして、最新の番号なリクエストが来れば最新の継続を、3つ前のバージョンのリクエストが来れば 3つ前の継続を、
引っ張り出してきて処理続行すれば、いいんじゃないかなと。
>私もいまPHPで簡単な認証システム作っているのですか、Time out後の処理とか、post受け付けURLをgetする、とかの処理で、
>どうすれば安全で便利なのか考えあぐねています。設計で予測されない応答をしてきたときは、どうすればよいのかな。
Timeoutっすか。俺のは考えてません。
だってDesktopがタイムアウト「ごとき」で消滅したら使えないっしょ、という
すごくスタンドアロン環境そのまんまの考え方なので(^^;
ユーザがログアウトしたわけでもないのに消滅しちゃ駄目じゃんという考え方。
なんならそのセッション(HttpSessionとかのほうじゃなく、Desktopのインスタンスという意味でのセッション)が
1年間生存してたっていいじゃん、と強弁しております。ぉぃぉぃ。
てゆーか、永続化しても違和感のないモデルを考えたら、それはアプリじゃなく
(アプリより一段大きい存在である)Desktopだった、という感じです。
俺の考え方は永続命なんで。
なお、HttpSessionという意味でのセッションが切れたら、画面ロックみたいな感じで捉えようと思っています。
ちょうどGNU Screenみたいな感じで、デタッチしたら後からアタッチするという感じね。
んで、イチゲンさんを捌く方法については考えてないんですよね(^^;