XULのための思考実験とその効率的なあり方？

XULなるものがある。
http://ja.wikipedia.org/wiki/XUL
XULとはUI（ユーザーインタフェイス）を記述するためのXML文書のことらしい。

V→UI→COM→C→M

今日はそんな話

Microsoftの.NET Framework 3.5 でのWPFアプリケーションを作る際のXSTLなんかとよく似ていると思う。どちらもUIを記述し、イベントを関連付けするためのものである。WPFは一度取り組んでみようとしたのだが、あまり便利だとは思わなかった。確かにUIの記述方法がマークアップ言語化されているのでWebでのデザインに慣れている人にはわかりやすいかもしれないが、これが要求するプログラミングスタイルはMC-Vである。ViewであるVがModelとしてのM、ControlとしてのCとは完全に分離していないといけない。Appleでのプログラミングを主とする人にはどうということはないが、一般的なWindwosApplicationProgramを行う人はMVCには慣れていない。CygwinでLinux環境向けに開発している場合も例外的である。
確かにVがMCと分離することには非常にメリットがある。それは見た目を変えても、関連付けさえしっかりされていれば、同等の機能を発揮できることである。これは再利用という面から見ても有益だ。
またMC-Vを推奨するならばCOM（Component Object Model)プログラミングの重要性も考えるべきだ。これは、Interfaceという考え方に基づいた汎用的あるいは抽象的なプログラムの駆動を制御するプログラミングモデルである。COMに基づくとその実装は知る必要はない（むしろ秘匿されている）。ただその制御の流れについては熟知していないとまったく使えないのである。
XULによるUI記述ならびにそれと特にCとの結びつけ。またこのCがCOMを採用し、一層、抽象層を継承して記述するならば、｛XUL（UI｝：V）→｛Interface→Control：C｝という流れを持たせられる。このときには特定の機能を実現するためのInterfaceを実装したものに付随するUIとしてSetに使えるようになる。ただここまで抽象化して、実装と分離すると、ブラックボックス的に動く部分が増えすぎて、破綻をきたしたときに対処することが容易ではない気もする。逆に分離されているから問題ないのかもしれない。
話はもどるが、XULでUI+Interface形式の記述を行うなら、Interfaceとその使い方が変わらない限り、UIの変更も、Control側のロジックの書き換えも自由だ。Interfaceという中間層で違いを吸収するようにすれば、デザイナとプログラマの仕事を分離できる。これがすばらしいのかどうかは分からないが、分業や専門性による分離が明確になる。まぁ、両方できるに越したことはないが。
追記
XUL ファイルは、どの要素が UI を構成しているか、どこに要素が現れているかを記述します。XUL 言語は制御に反応してどういう働きがあるかをプログラマが定義することを許す属性を定義します。動的なアプリケーションのふるまいを定義するために、ある場合には特定のユーザインタフェースイベントが発生したときに呼ばれる JavaScript 関数を定義することが出来ます。それらの JavaScript 関数の中では、直接アプリケーションのふるまいを記述するか C++ で定義されたロジックを含む COM オブジェクトの利用可能な他のアプリケーションロジックを呼び出すかすることが出来ます。
引用元：https://developer.mozilla.org/ja/Mozilla_Hacker's_Getting_Started_Guide
やっぱりCOMの考え方は使われているというオチ。まぁスクリプトに関してJavaScript　Onlyなのは、多言語対応がややこしさを持ち込むのからだろう