承認依頼について

承認機能は「承認依頼」「承認」「却下」の3種のactionがあれば一周回ると思います。
大事なのは、「承認ルート」の扱い方かと。

で、承認依頼ですが、一度実装してみたところなんとなく考えるべき要素が見えてきました。

カスタマイズ可能にするのであれば、承認ルートを作り出すロジックをクラス化しておき、
そのクラスパスを設定で指定する、というスタイルがよろしいかと。
ただし、「標準機能」として提供する場合どういったパターンを用意しておくべきか考えねばなりません。
思いつくのは次のパターンです。

完全自由指定	承認してもらいたい人物を選択させるパターン。
回数ベース	遡る回数をパラメータ指定し、その回数分上司を遡って承認してもらうパターン。
ロールベース	直属の上司から最終承認権限を持っている上司まで遡って承認してもらうパターン。

書いてみて気づきましたが、実行時パラメータは1番目の完全自由指定でいいような気がしてきました。
ただし、設定パラメータ（DBにactionを登録する際のパラメータ）として入力支援としてルートを計算するクラスを指定できる、みたいな。

実際には、指定されたクラスを使って初期値を設定しておき、画面側では必要に応じて承認者の変更を可能にする、という感じになります。

これで行ってみます。

でもま、結局は業務毎に承認ルートを計算するクラスは必要になるんじゃないでしょうかね〜。

※追記（2013/10/14）
とんでもない間違いをしてました。
「承認依頼」と「承認ルート取得」は独立させるべきですね。なんでこんな事に気がつかなかったのか・・・
というわけで、「承認ルート取得」Actionを追加します。
１アクションはシンプルに。