- » Kindle
- » iBooks
- » kobo
- » B.W.
- 400円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 490円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 100円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 300円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 600円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
doncha.net制作・発行:KindleやiBooks、楽天kobo、BOOK☆WALKERで読む電子書籍
入力formをAjaxにすると
状態が変わった場合に、同じページのほかのコンテナの表示も変えないといけないケースがけっこうあるぞ。ページごと移るなら話は単純だけど。
ううむ。気づいてなかった。入力した、もしくは削除したのに、ページ内の表示が変わらないのはマズイ、ていうか、そんな腐ったページはありえない。
なにかアクションを起こしたら、必ずそれがわかる、てのが世の中の大原則、いわば等価交換だ(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時間が短かいと確実じゃないし、長すぎると連打されて簡単に負荷がかけられる。クライアントを固めるようなことになっても、更新系がからむところは同期でいくほうがいいよなぁ。どっちにしてもあちこち見直しが必要だわ。ふうう。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」