XAML with .NET Framwork / XUL with Java
http://linuxtoday.com/developer/2004022402326OPCYDV
いつぞや俺が構想してたことと同じ事を提案してた。XMLによるユーザインタフェース定義って、グラフィカルユーザインタフェースビルダとも親和性が高いと思うし、そういう方向性で伸びればいいなぁと。
しかし現実的な問題として、以下の二つのテーマについて考慮すべき所があると考えている。XAMLではそこをうまくやってくれていたりして、XAMLとXULが競争しあってよりよいものになることを願ってみたりする今日この頃。
まず、XULにおいて、それぞれ以下のようになっている。
- XBLによって他のXMLに置き換え、それにCSSを適用することでウィジェットの外見を形作っている
- HTML中のJavaScriptイベントハンドラと同じ扱いになっている
それぞれの問題点として次のようなことがあると考えている。
- 最終的なDOMツリーがかなり複雑な構造になっていて、それら全体を保持するためにかなりメモリを食うだろうこと。また、CSSによる外観の指定はかなり重いだろうこと。更には、Mozillaでスクロールバーやツールバーなどウィジェットの外観を結局はネイティブウィジェットの見た目に似せるために腐心していること。ネイティブウィジェットの外観と感触(Look and Feel)を再現する最良の方法は、ネイティブウィジェットを直に使えるようにすることである。
- XMLに埋め込む時点でイベントハンドラはCDATA(文字列)であることを期待されていること。つまり、ユーザインタフェースのイベント処理を常に何らかのインタプリタを介して行う必要がある。これは、低速になる原因となっていると考えられる。Mozillaについては実際にはDOM Eventインタフェースを通じて、JavaScript側からイベントハンドラを追加することができるようになっているので、同様の方法でDOMにイベントハンドラを追加する仕組みを作れば、非インタプリタ言語によるイベントハンドリングも実現できると考えられる。
XAMLでは、XMLの各要素をネイティブウィジェットに割り付けるようになっているので、1.の問題は解決されていると考えられる。さらにボタンをクリックしたときの反応など、デフォルトの動作はネイティブウィジェット自体が持ってるので、かなり反応性がよいことが想定される。2.についても言わずもがな、.NET Frameworkに対応した言語でXAMLにアクセスできるように作るとしたら、上の2.で提案したような仕組みにならざるを得ないであろう。
結論として、XULはWebアプリケーションを意識しすぎて、HTMLと埋め込みJavaScriptによるイベント処理という形に拘りすぎていると思う。つまり、XULが主で、イベント処理を含むアプリケーションロジックは従である。しかし、実際にはユーザインタフェースを必要としないアプリケーションも多々あり、例えばXULの枠組みを用いてhttpdを書こうとしたら、必要が無くともウィンドウを開く必要がある。これは、現実に即していない。アプリケーションロジックが主でXUL的なものが従になる設計が必要ではないかと考える。
