Teedaはじめました-PRGパターン-

「PRGパターンについて」を読んで、初めてこういう便利なパターンが存在していたことを知る(汗。「この画面でユーザがRELOADボタンを押したら何が起きるか？」「そこで変なことが起きないためにどうしておけばよいか」なんてことは、誰かに言われる前に対処しておかなきゃいけないんだけど、なかなか徹底できないんだよね(大汗;

ふつうsubmitはpostして、次の画面はforwardで決めてた。redirectはclient-server間を2往復するし、requestを引き継いでくれないから別Webアプリケーションへ転送するとき以外は使ってなかった。でも前者はいまどきそれほどシビアな問題でもないだろうし、後者はTeedaが面倒見てくれるなら、得られるメリットの方が大きい。

でも読んでいて飲み込めなかったのが次の１文。

forwardベースでRELOADされたときにPOSTされてしまうのは POSTで使ったresponseをそのまま使用しているためです.

うーん。この文は「ブラウザのRELOAD(REFRESH)ボタンを押されるとき、意図しない処理が実行されたり、あるいはサーバのモデルが変更されてしまう理由」を意図していると思うわれるが、それだったらresponseじゃなくてrequestの方がすっきりするような。ただそれは「使用している」の主語が「サーバ側アプリ」と仮定しているからで、それ以外ならresponseの方が適切なのかもしれないけど...。

どうもすっきりしないので、いろいろぐぐってみたところ自分の考えに近い記述を見つけて一安心。

But in fact to refresh the result page would mean to re-issue the same request to the server which was used to obtain the page at the first place. That means, to do the whole POST of the form from the first page again.

Post/Redirect/Get pattern for web applications

つまりPOST/forwardで遷移した先の画面でreload/refreshすると、遷移元画面でsubmitしたのと同じことが起こる。だから遷移元画面で押したボタンが[商品購入]だったりすると、まずいことになる、ということだよね。まぁそういうことにしておこう。