Zend_FormとZend_Dojo_Formの微妙な関係

モデル定義はアプリケーションに制約されたくない。

モデル周りのFW雑感

Webフレームワークの多くでは、アプリケーションをスピーディーに開発するためのモデル定義のセオリーみたいなものがある。
自動でデータベーステーブルを作成してくれたり、テーブルに合わせたフォームを自動育成することもできる。無論、それらは作成後、カスタマイズされたテーブルやフォームに変更することもできる。
フレームワークが提供する機能を使えば、モデル定義を定式化して開発効率や保守性を向上することができるが、一方、それらの機能の利便性を享受すればするほど、ある限界にモデルを制約することになる。便利さの禍福というべきか。
ZendFrameworkは他のフレームワークに比べると制約が少ない。その分自動化されていない部分については自前で自動化する必要がある。

Zend_Formの場合

たとえば、Zend_Formはモデルとビューをつなぐフォームをハンドリングするための枠組みを与えてくれている。ZendFrameworkを使うならこれを利用するのが自然な方向性になる。実際、設定ファイルを一つ書けば複雑なフォーム構成もスピーディーに展開することができるので、機能的には満足している。
Zend_Dojo_Formについても同様で、これを使えば、Dojoベースの複雑なウインドウ構成の中にAjaxを利用したインタラクティブなインターフェースを素早く構築することができる。

プロトタイプを作成してみて

Zend_Formのテストは速やかに終了したが、Zend_Dojo_Formのテストにはしばらく時間がかかった。Zend_Dojo_Formを利用したプロトタイプ的アプリケーションを作成してみて、その出来栄えと開発効率にはおおむね満足している。そこで、次の段階としては、同じモデルで同じ動作をするアプリケーションをDojoを使わずにプレーンなXHTMLだけで再構成すべく抽象化することを考える。
フォーム作成時にZend_Dojo_Formを指定していたところをZend_Formに変えるだけで、ある程度動作してくれるような書き方にしたいと考えてみる。
いやせめて、出力段階で分岐できないだろうかと。

解決策はコンフィグレベルで

iniファイルの記述の仕方で、プレーンなXHTMLにした場合と、dojoを利用した場合とで、共通する部分とそうでない部分に着目し、Zend_Configが持っている継承機能を利用するという手が一つ。（たとえば、baseセクションでフォーム構成の基本を決定し、Zend_FormセクションでZend_Formに標準で付いてくるエレメントに対する設定を書き、Zend_DojoセクションでZend_Dojo_Formに付属してくるフォーム要素に関する記述を書く。）
コンフィグの各要素内に識別子を持たせフォーム育成時にフィルタをかけて絞るという手が一つ。(たとえば、要素タイプを標準ではText、dojo用にはTextBoxを設定する。)
前者で行く方が無難だろうとは思うのだが、残念なのはエレメントタイプ名をもう少し考えてほしかった。もしくはエイリアスの指定ができるだけで汎用性はかなり違う＝コンフィグの記述が楽なんだよね。どの道、プラグインローダーで検索パスの優先度でクラスが決定されるわけだから。

妄想：抽象化クラスを挟むか

エレメントをHTML要素に直結させるのではなく、データ型による抽象レイヤーになるようなデータ要素クラスを作成し、状況に合わせてフォーム要素クラスを自動判別するようなものを作ればいいのかもしれない。
この抽象化クラスはモデルの起源的に扱うことも可能かもしれない。
これなら、コンフィグの継承で複雑な書き方を指定する必要もなく、フォームクラス、エレメントクラスの変化はオプションの中に隠ぺいすることが可能だ。