フォームスタックとPRGとFlashMessenger

寡少な画面の中でのフォーム遷移を想定するとき、
たとえば、ブログ全体の管理画面からカテゴリー編集画面を呼び出すケースと、アイテム編集画面からカテゴリー編集画面を呼び出すケースを想定すると、
フォームがスタックされて、処理が終了したらそれぞれ呼び出し元に戻りたいと考えるだろう。
Yahoo!などでは.doneとか.bailなどにパラメーターを載せて独立したサーバー間でのリダイレクトがうまく動作するように定式化されている。
Androidのフォーム遷移はフォームをうまくスタックして、処理が終わったら元に戻るような実装になっている。Webでもセッションが生きているならセッション内にそういったデータを保持することで同様の処理にできる。
PRGパターンでポストデータの処理後はredirectというのを徹底しておけば、ある処理の終了後のredirect先は、呼び出し元の画面になる。
そこで、Zend FrameworkでのFlashMessagener RoRなんかのFlashを使って終了後メッセージを送りだす。

画面数が限定的に全体を支配していれば、このあたりの処理は簡単にまとめることができると思うが、たとえばDojoやExtなんかでウインドウベースなアプリケーションを組んでいく場合、redirectではなく単純にタブを閉じるとか、サブウインドウを閉じるとか、モーダルな画面を閉じるとか、要するに閉じる動作で事足りる。
データの更新が済んだら、セッションから該当フォームを削除してレスポンスJSONに閉じろと命じればいいわけだが、これはredirectよりはやや複雑かつAjax実装に依存することになる。
仕様を厳格に決めればAjax側でということになるのだが、境界が２本ある状態は開発リソースを考えるとややもったいない感じがする。

すると、処理完了時のメッセージングをいったん抽象カプセルに落とし込んで、処理ポリシー毎の違いを吸収できるような仕組みを用意した方がいいだろうと思われる。