アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
エラーメッセージ（オフトピ） (スコア: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窓を作るのを「放棄」するという逃げは可能だが、それはあくまで逃げ。
だってさ、画面遷移しか出来ないのだとしたら、Gotoは出来るけどCall-Returnは出来ないっていうDQN言語と、似たような状況だよ？
＃ま、それは継続を扱える言語ならドレでも実現可能なんだけどさ。
＃RubyとかSmalltalkとかででも「継続ベースのwebアプリケーション」(←この言葉でググってみるといいよ)環境を作ってる人はいろいろ居る。
俺も、
○Widgetベース。画面遷移は完全に隠蔽しちゃう。Windowなどのオブジェクトを表示する。
○Web「アプリ」のインスタンスがセッション上に複数(同種でも異種でも)同時に存在し得る、「デスクトップ」的な世界。
○表示画面の世代を自動管理するので、「戻る」や「Reload」などのWebブラウザのヤンチャな挙動にも一切惑わされない。
っていうWebアプリ環境なら試作してみたことあるけど、上記のDialogを作ろうとしてハタと困った。
Dialogは書けないのな。
打開する手は3つしか無い。よほど一般受けしないトリッキーな仕組みを持ち込むか、アプリ側のプログラマが泣いて頑張るか、
さもなくば継続を使うか、だ。
＃って、rubyで書いてるんだからContinuation使えばいいのに。使ってないのは単純に俺がまだ理解してないからだ(藁
---
さて。WebアプリでScheme使うか？とか、それ以外ででもScheme使うか？とかいう話題については、
やっぱり、それこそKahuaの中の人(だよな)でもある Shiroさんち [dreamhost.com]を参考にするのが吉でしょう。
勿論それがあっち側の人の言葉である以上、こっち(?)側の人も幾らでも反論は考えられるだろうけど、
(今となってはさすがに、Schemeに絶対的優位性なんてものは無いからね…)
少なくともこれだけ「高級」なプログラミングを何十年もやって洗練してきたLisp/Scheme畑ってのは、
こっち(?)側の人も恐怖(?)の念を持って見たほうが良いと俺は思う。
たとえば、世間が最近やっとClosureの恐ろしさを理解しはじめたような気がするんだが、
彼らはそんなの何十年も昔からやってるのね。
そして継続の恐ろしさに至っては、ほとんど理解されてねーだろ。便利なのは目に見えてるのにだ。
理由は簡単で、便利かどうか見るという段階にすら、まだ至ってないからだ。
＃Closureについては、極めるイテレータ [loveruby.net]とか、
＃http://prdownloads.osdn.jp/seasar/9108/KarasawagiDoc.zip の xml_must_die.pdf を見てやってね。
＃今までClosure無しでやってた色々なこと(プログラミング技術とか、XMLとか…)が、なんとも馬鹿馬鹿しく思えてくるからさ。
＃あと継続の説明については、すげぇ判りやすいのがこのなんでも継続 [dreamhost.com]ね。
具体的な話はともかく、考え方として重要なのは
なんつっても、俺もよく引用する「普通の奴らの上を行け」の「「ほげ言語」のパラドックス」という奴でしょう。
自戒をも込めて、この言葉(の意味)は把握しておいたほうが良いと思う＞皆様
少なくともClosureや継続をスイスイやれるようになってる人でない限り、「Scheme(中略)DQN」みたいなことは言う資格(?)は無いだろうな。
だって、レベルが低いのはソッチなんだもん。
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のインスタンスという意味でのセッショ
Re:エラーメッセージ（オフトピ） (スコア:0)
あとlispとweb application の親和性のもうひとつにs式がありますってこれは使い古された話か
Re:エラーメッセージ（オフトピ） (スコア:1)
あれれ？そうですか？
元々俺は「継続とは何か」とかいうことをあまり語っていないぞ、ってのも有りますが、
俺の継続ネタはkahuaていうかGaucheのShiroさんに直接色々聞いたネタなので、
それで尚間違っているっていうなら、俺が余程すごく間違ってるってことになるんですが、
そうなんでしょうか？
＃てゆーか、どこがどう変だと書いてくれてないってのが…
>あとlispとweb application の親和性のもうひとつにs式がありますってこれは使い古された話か
ですね。S式の強み(の1つ)をClosureとしての性質だと捉えるならば、 HTMLを楽に作る手段としては、
それはRubyやGroovy(ほげほげMarkupBuilderと呼ぶようです)でも常用されてますし。