webアプリの抽象化について考える6

次に、各機能に共通なコードとは何があるであろうか。考え付くところとしては、

  • セッション管理
  • アプリの設定
  • データベース接続
  • 認証
  • ユーザの入力の妥当性チェック

なんてところですか。
ユーザ入力以外は、各機能ごとのコードを呼び出す前にやれば良くて、PEARでも使えばできるだろう。使うライブラリを決めておく(つまりはAPIを決めておく)ことに意義が有る。
ユーザの入力の妥当性チェックは、画面の遷移が入るので若干複雑だ。たとえば、入力に間違いがあれば、元の入力画面に戻した上でエラーメッセージを表示させるとか、エラーメッセージだけの画面を表示した上で、元の入力画面に移動するリンクをたどらせるとかの方法が考えられる。
これは、ある機能のMを処理する部分を実行したところで、入力にエラーがあれば、別の機能に遷移するということである。
ということは、各機能ごとのコードは、1つにまとめるのではなく、MとVに対応する二つにまとめる必要があるということになる。その上、M処理部分を実行後、エラーの有無を知る必要がある。
となると、「グローバルレベルのコードをincludeする」というコードのまとめ方よりも、機能ごとに関数を用意する方がエラーの有無を感知しやすい。関数かクラスかということになれば、その柔軟性からクラスを採りたいことろだ。

各機能ごとのコードを2つに別けたところで、遷移を始めることはできるようになるが、遷移先をどうすればよいのだろうか。間にエラー画面を挟むにしろ挟まないにしろ、ユーザ入力が行われた画面に遷移する必要があり、また、エラーがあるにしろ入力されたデータは遷移後も保持している必要がある。
これは、ユーザ入力フォームをクラスで抽象化して、そのクラスに入力画面の情報を持たせるようにすれば良いだろう。
では、入力画面の情報って何になるだろう。

  • 機能の名前 (index.php?op=showのshow)
  • GETやPOSTで渡されたパラメータ値
  • ユーザ入力フォームのID

でしょうね。リファラでわかる情報もあるが、リファラは隠されていることもあり、使用できない。hiddenフィールドで保持する必要が有るだろうね。
このユーザ入力フォームクラスをどう実装するかが、webアプリのフレームワークの肝になりそうに感じる。HTML_Quickフォームを上手く拡張してやることで出来ないだろうか。