状態が変わった場合に、同じページのほかのコンテナの表示も変えないといけないケースがけっこうあるぞ。ページごと移るなら話は単純だけど。

ううむ。気づいてなかった。入力した、もしくは削除したのに、ページ内の表示が変わらないのはマズイ、ていうか、そんな腐ったページはありえない。

なにかアクションを起こしたら、必ずそれがわかる、てのが世の中の大原則、いわば等価交換だ（by フルメタルアルケミスト）

Ajaxを使った入力formでデータの状態を変えたら、データを表示しているコンテナに反映させるためのRequestも必要ってこと。んでなんでAjaxかというと非同期だから。…これで、たぶん、まぬけにハマる。

new Ajax.Requestあれこれ

この時点で、デフォルトだと、返事が帰ってくる前に別の処理を始められるのがAjaxというやつ。これがチョー便利なんだけど（初老のおっさんが「チョー」はない）、だけど、今回の入力formとその反映を考えると返事を待たなきゃいけないぢゃん。

Ajax.Requestを複数仕込む時に。

new Ajax.Request あれこれ

new Ajax.Request あれこれして変更されたデータを取得

最初のpostするRequestはデフォルトを同期に変更して、次のgetするRequestは非同期。てことでイケる…ような気がしてきたぞ。週末にでもちょっと試してみるか。だめならperlの側でsleepをいれてごまかす、というのもありだな。

にしても、案の定、というか無知なままのJavascriptなんかを使うんでハマりまくりだ。でも、Ajaxは流行だし、わたしは流行に弱いミーハーだし（あれ？もしかして、ミーハーも死語かな）

まだ先は長かった、か。とほほ。

夕方のスコールが続いたかと思ったら、いきなり涼しい都心だ。

[08/22 23:23:39]

なんか今日もこき使われてへとへとの図。牛馬だぜ、やれやれ。こんなじゃ青空所属も近いな。と、ぶちぶち言ってもしょうがない。

で、検索してみたらやっぱり、Ajax.Requestで「非同期」じゃなくて、同期通信の要望・ノウハウがちらほら。そりゃそうだよなあ。更新系がすんでから、それを閲覧、というのが普通だ。その一方で、

サーバー側がコケるとクライアントが固まるから、同期通信は「推奨」されない、てのももっともな話。

うううむ。非同期でやると、サーバー側perlにsleepさせるしかないけど、sleep時間が短かいと確実じゃないし、長すぎると連打されて簡単に負荷がかけられる。クライアントを固めるようなことになっても、更新系がからむところは同期でいくほうがいいよなぁ。どっちにしてもあちこち見直しが必要だわ。ふうう。