Please note, this is a STATIC archive of website developer.mozilla.org from 03 Nov 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.
検索結果

    Introduction to XUL

    メインページ » 移行してきた文書 » （※外部サイトからの移行）
    この記事は Mozilla Japan 翻訳部門または関連グループにより過去に翻訳された文書を移行したものです。 移行元の文書。よって、英語版と内容が異なる場合や、MDN の他の記事との整合性がとれていない場合があります。

    This article is a bit outdated and needs to be updated.

    前置き

    Mozillaはコンフィグレーション可能で、ダウンロード可能な chrome(クロム)をもっている。 つまり、メインウィンドウの組み立てやさらにコントローラの有無でさえもアプリケーションに ハードコーディングされているのではなく、別のUI記述から読み込んで来る。実際、 Mozillaのウィンドウ(とダイアログ)のほとんどはこの機構を用いて書かれている。 XUL(そのつづりから"ズール"と発音される.また"XMLベースのユーザインタフェース言語"の略である)は これらのUI記述を組み立てるための言語の我々の名前である。

    ウィンドウ クロムはブラウザの中でHTMLコンテンツを管理しているのと同じ レイアウトエンジンにより表示され、管理される。そこでは、UI記述はHTML 4と大変良く似ている. XULはXMLの1アプリケーションである。実際、XULはいくつかのエレメント型に特定の意味を定義した XMLそのものであり、XUL記述の中にHTMLが点在していても構わないのである。

    用語

    "XPFE"はMozillaブラウザのクロスプラットフォームフロントエンドを表す 用語としてMozillaの組織では利用されている、なぜならXとCは,もしハンマーで叩いて長く硬くしたら よく似ているからである。その趣旨はクロスプラットフォームアプリケーションを作る目的で設計された ツールの集まりからブラウザやメールクライアントのようなクロスプラットフォームアプリケーションを構築することであり、 汎用のクロスプラットフォームアプリケーションフレームワークを実装することではない。 これは既に実行に移されており、大変大きな仕事である。我々はブラウザのようなネットワークアプリケーションを構築するのに 適したクロスプラットフォーム機能を提供するするつもりであり、クロスプラットフォーム機能はすでにMozillaのHTMLレイアウト エンジン,Geckoに実装済である。

    "クロスプラットフォームUI"という用語は幾分紛らわしい。UI設計者は複数のプラットフォームで動作するUI記述を作ることが できる。しかし、ダイアログのボタンのようなものの適切な配置に関して、さまざまなプラットフォームの異なる考えを考慮した 適切なUL記述をおこなうには若干のプラットフォームに依存した記述が必要になる。 XUL仕様単独では、ある程度クロスプラットフォームが可能というだけである。 UI設計者とビルドエンジニアは少なくともいくつかのプラットフォーム依存XUL文書を分けてメンテナンスする必要があるだろう。

    "XPツールキット"はXPFEと幾分類似している。けれども前者は後者に比べてより具体的であり、 従って完全に置き換えられるものではないがなぜ2つの用語が存在するのかについては誰も確かではない。

    "XUL"はすでに紹介した。これは Mozilla のウィンドウのほとんど,特にメインブラウザウィンドウを含む、の レイアウトを記述するのに利用するXMLの1アプリケーションである。

    範囲

    この文書は要求仕様を述べることは試みていない。我々は現時点での"要求仕様"文書をもっていない。 XPツールキットアーキテクチャはこれらに関する理解を得るには良い場所である. この文書は, Mozilla フロントエンドアーキテクチャに関する簡単なイントロダクションを含んでおり,UIの構築に関する 説明に的をしぼっている.それは、いつものように不完全である.

    Mozilla アプリケーションはダイアログボタンやメールボックスフォルダのような"小さな"コンポネントから構成される。 これらをまとめてウィジェットと呼ぶ。ウィジェットにより描画とユーザとの対話は個々のウィジェットの制御下に置かれ、 それはウィジェットが生成された時に設定される。 ウィジェットの配置と共に,ウィジェット間のお互いの会話,また時にはそれらの設定が スクリプトによって指定されるUIレイアウトによって制御される。そのスクリプトの構造は この文書、あるいは他の関連する文書にて定義される。

    ウィジェットは主としてアプリケーションが自分自身に含んでいる断片であり、一般には ウィンドウの領域の長方形に対応する。ウィジェットは一般に動的にロードされるライブラリ に分けて集められている。あるウィジェットはウィンドウの一部(ツールバーとかツールバーを集めたもの) をもつことを想定しているかも知れない。あるいはウィンドウと一緒に動作すること、あるいはウィンドウなし で動作することを想定しているかも知れない(プラットフォームに依存したメニューバー)。 全くアプリケーションのUIの一部ではないのかもしれない。

    ウィジェットはコンパイル時に前もって定義された振舞をもつ。 ボタンはマウスに反応し、ツールバーはボタンを集めたコンテナとして動作する。 ウィジェットがそのアプリケーションにもたらす効果はあらかじめ定義されたアプリケーションの振舞と ウィジェット間のリンクの組合せとして定義される。このリンクは XULに含まれているJavaScriptによって, あるいはXULから構築された後,コンテンツモデルを走査し、イベントリスナを仲介するアプリケーションコードに よってなされている。一般に、実際のアプリケーションはこの2種類の組合せを利用している。

    アプリケーションは、例えば"ファイルを開く"コマンドを受けたとき何をするかについては 前もって知っている。"開く"ボタンは単なるボタンである。ボタンは一般にはリンケージのために 単純なJavaScriptを利用して、コマンドを処理するアプリケーションに送信する。

    我々は最初に明白なUIコンポネント、ツールバー、メニュー、ダイアログに焦点をあてたいと思う。 概念的に、XUL言語はこの(全ウィンドウの一番上にメニューバーをもつようなあるOS上で動くアプリケーション) ように指定することによって、いっしょに動作するコンポネントのパッケージを指定してテキストエディタで編集することができる。: 

    main window containing
 menubar area at top across width of window containing
   menubar (and its contents)
 toolbar area below menubar across width of window containing
   main toolbar (and its contents)
 application-specific content area below toolbar area

    XULファイルの構造

    我々が選んだ言語は表示情報をCSSで味付けした XMLである。 XMLの特定のアプリケーションの詳細、 つまり特定のツールバーに関する文法については 特定のアプリケーションについて記述した別のドキュメントに委ねる 最新のリストについてはXPツールキット インデックスをチェックすること。

    XULはウィンドウのレイアウトを記述するための言語なので、 このドキュメントが対象とするトピックとXUL[windows.html windows]について記述した 別のドキュメントで重複する部分がある。XULのウィンドウに関する記述を書くという作業は、 文法がXMLである(HTML 4とは違わない)ということ、XULに特有のエレメントがあることを除いて 基本的にHTMLでコンテンツを書く作業と同じようなものである。 これらのエレメントは以下に述べるようにウィンドウの振舞と結びつけるウィジェットと特定のインフラである。

    XULドキュメントを書くことの細部のほとんどは、XMLドキュメントを書くこととほとんど同じである。 XMLドキュメントの記述については他の優れたXMLに関するドキュメントに譲ることにする。そのような ドキュメントは存在するに違いないと思うが我々はまだ見たことがない。 本ドキュメントではXULに特化した点に集中することとする。

    単語の大小文字識別と名前空間,ファイルタイプ

    XMLはもちろん大文字小文字を区別する。XULでも同じである。 我々の現在のコードはこの 特にHTMLネームスペースのタグと属性についてはこの制限について厳しくしない傾向にある。 タグと属性についてはルールとして、XHTML ワーキングドラフト の中で提案されているように必ず小文字で書くように今後変わっていくであろう。

    Mozillaでは XULファイルに特別の意味をもたせている。これはこのことによってその中からUI記述を見つけることを 期待している。この理由により,我々は.xulの拡張子をもつファイルに対応するMIMEタイプ"text/xul"を定義している。 (標準に準拠するために,おそらくこのmimeタイプを"text/x-xul"だかなにかに変更する必要が生じてくると思われる) この種のファイルは"text/xml"のファイルと同じパーザを用いて処理される(また、それゆえに"text/xml"タイプの ファイルがそうであるようにXMLの文法ルールに従うことになる).(*.xmlという名前の)XMLファイルからXULドキュメントを 読み込むことは可能である。その結果生じるUIはXMLコンテンツモデルを利用して生成されるであろう。XULコンテンツモデルは *xulファイルから生成される。XMLドキュメントは基本DOM Level1 Core APIをサポートする。 HTMLドキュメントがDOM Level 1 HTML APIをサポートするのと同じように、XULドキュメントは拡張セットをサポートする。 Mozilla のXULコンテンツモデルは ローカルのファイルとリモートのファイルのマージのような素晴らしい機能もサポートする。 詳細はXULとRDFドキュメントを参照のこと。 一般には、XULは*.xulファイルに格納したいと思うだろう。

    XULファイルはXULに特化した特別のエレメント：XULエレメントと同様に、XMLエレメントやHTMLエレメントも含むことができる。 XULの(もしHTMLエレメントが使われているならHTMLも)ネームスペース宣言が ファイル中に含まれていなければならない.ネームスペースは慎重に取り扱う必要がある.正しいネームスペースの使用によって ネームスペースが個々のアトリビュートにではなく,タグのためだけに利用されることを必要とする この規則に対するまれな例外がバグである。

    XULファイルの序文

    XULはXMLである。また、正しいXULファイルは標準のXMLバージョンとDOCTYPE文で始まる。

    XMLでは暗黙の表示セマンティクスは用意されていないので常にスタイルシートと関連づけられなければならない。 Mozillaは標準のスタイルシート"xul.css"をもっている。 常に、最初にこのxul.cssを読み込むようにしなければならないが、繰り返しの処理命令を利用したがるのと同じように たくさんのスタイルシートを読み込むことができる。 そして最後に、ドキュメント中で利用するネームスペースは全て宣言されている必要がある。 よって、XULファイルの以下のような始まりになるだろう 

    <?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/xul.css" type="text/css"?>
<!DOCTYPE window>
<window xmlns:html="https://www.w3.org/1999/xhtml"
  xmlns="https://www.mozilla.org/keymaster/gat...re.is.only.xul">


    HTMLネームスペースはもちろん標準のものである。XULネームスペースは明らかに一時的なものであるが、 少なくとも発音の説明には役にたつ。 上記の例では暗黙のXULネームスペースを利用していることに注意するように. これは任意である.本ドキュメント中の他の例では折に触れて、ネームスペース利用の度にいちいち 明示することの問題点について論じたいと思う.

    chrome プロトコルは クロム記述中に含まれているファイルの正確な位置が移動されても XULソースにはなんら影響がないようにしたMozillaのもう1つの拡張である。 したがってこれは遠回しである.いつか[packages.html パッケージ]にこの機構についての 完全な記述が載るであろうが、現時点ではいいドキュメントなのだが幾分時代遅れになったのが 設定可能なクロムにある。

    スクリプティング

    XULインタフェースはそれがプログラムされるまでは接続されていないウィジェットを集めたものに過ぎない。 "プログラミング"は複数のウィジェットを結びつけて特別の機能を与えるJavaScriptのように簡単にもなり得るし、 なんでもできるC++アプリケーションコードのように複雑にもなり得る。 本稿ではアプリケーションプログラミングはその範疇を越えるものと考え、JavaScriptにしぼることにする。

    JavaScript

    XULにはJavaScriptを含んだHTMLコンテンツを含めることができる。JavaScriptの関数もHTMLと同じように 書き足すことができる.XULファイルには<head>セクションがないので スクリプトは他のコンテンツに混ざっていて,HTMLネームスペースの<script>タグで切り分けられる。 

    <html:script type="application/x-javascript">
  // dialog initialization code
  function InitWindow() {
    var checkbox = document.getElementByID("remember");
    if (checkbox)
      checkbox.checked = true;
  }
</html:script>

    JavaScriptはHTMLドキュメントの時と同じようにonClickハンドラと同種のものとして 参照が可能である.JavaScriptのバリューを受け入れるアトリビュートのリストのために indexで参照されている個々のウィジェットのドキュメントを参照してください。

    JavaScriptは最も安全に別のファイルに分けて以下のようにしてXULファイルに取り込むことができる 

    <html:script language="javascript" src="our.js"/>


    あるいはXMLコンテンツのように見えるかもしれないJavaScriptがXMLパーザを塞ぐかも知れないのを防ぐために CDATAセクションのコンテンツとして追いやることもできる(例えば,<キャラクタ) 

    <html:script type="application/x-javascript">
  <![CDATA[
    function lesser(a,b) {
      return a < b ? a : b;
    }
  ]]>
</html:script>

    JavaScriptの拡張

    Mozillaでは、厳密にはブラウザの環境に含まれていない新しい機能をサポートするために JavaScriptにいくつかの拡張を行う必要が生じた。 これらは標準に準拠していないがもちろん今では変更の余地は残されている。 個々の拡張は拡張を必要とする機能に関する個別のドキュメントに記述されている。

    DOMの拡張

    XULはHTMLと同じものではないので、XULドキュメントがDOMレベル1コアAPIをサポートしていても XULドキュメントはDOMレベル1HTML APIをサポートしない。しかしながら、MozillaはHTMLを拡張した後合わせられた XULコンテンツモデルのために拡張DOM機能性をサポートする。 現時点ではこれらの追加されたDOMメソッドは、コードがこの情報を探すのに最も敵した場所だけれども利用可能である。 これらのインタフェースはディレクトリmozilla/rdf/content/public/idlから見つけることができる

    XULDocument

    XULDocument は HTMLDocumentの拡張のときと同じ方法で Documentを拡張したものである。 

    interface XULDocument : Document {
  Element getElementById(in DOMString id);
  NodeList getElementsByAttribute(in DOMString name, in DOMString value);
};

    getElementById はHTMLのgetElementByIdと同じように動作する。

    getElementsByAttribute は指定された名前の属性が与えられた値をもっているElements のリストを返す。 "*" の値はその属性をもつ全てのエレメントを表すワイルドカードである。

    XULElement

    XULElement は Elementを拡張したものである。 

    <xul:window xmlns="https://www.mozilla.org/keymaster/gat...re.is.only.xul">
 <broadcaster id="canGoBack"/>
 <titledbutton src="resource:/res/toolbar/TB_Back.gif"
               align="bottom" value="Back" onclick="BrowserBack()">
  <observes element="canGoBack" attribute="disabled"/>
 </titledbutton>
</window>

    getElementsByAttribute 関数はXULDocumentに同じ名前の関数があるが、 このバージョンは与えられたエレメントの基準を満たしなおかつ与えられたエレメントの子孫(CSSのセレクタ用語)である エレメントのみを返すものである。

    XULElementもまた、XULドキュメントローダによって自動的に実行される、ブロードキャスタ間を仲介するという機能, 従って通常のJavaScriptでは利用されない他のメソッドをサポートする。

    XUL エレメント

    上述したように、XULファイルは、ほとんどXMLの文法に従ったHTMLファイルである。 XULファイルはHTMLエレメントしか含んでいないかもしれないし、完全に機能本位のものであるかもしれない。 しかし、XULではいくつかのエレメント型を独自に定義しており、それらはウィンドウに機能性を追加するものである。

    ウィジェット

    ウィジェットは一般にボタン、テキストボックス、ツリーコントロールなど、フォームコントロールのようなオブジェクトである。 ウィンドウには他のHTMLコンテンツと同じように簡単に(htmlネームスペースを使って) HTML形式のエレメントを含めることができる。(でも,そのHTMLエレメントを<form>タグでくくる必要はない) 実際、各ウィジェットではそれ自身を記述するするためのXML文法を独自に定義している.詳細については 索引で参照されているウィジェットのドキュメントを参照されたし。

    他のインフラ

    ウィジェットはちょうどHTMLのようにJavaScriptイベントハンドラをもっていることがあり、 それはJavaScriptとブロードキャスタノードを使ってお互いに結びつけられている。 ブロードキャスタノードはXUL記述の中で<broadcaster>エレメントで宣言されており、 ウィジェット間の状態変化のやりとりに利用される。1つ、あるいは2,3のウィジェットでそのうちの１つの属性の値が ブロードキャスタノードに結びつけるように組み合わせるようなことも可能である。この結びつけはXULではこのように定義される: 

    <xul:window xmlns="https://www.mozilla.org/keymaster/gat...re.is.only.xul">
 <broadcaster id="canGoBack"/>
 <titledbutton src="resource:/res/toolbar/TB_Back.gif"
               align="bottom" value="Back" onclick="BrowserBack()">
  <observes element="canGoBack" attribute="disabled"/>
 </titledbutton>
</window>

    しかし,ブロードキャスタをウィンドウに配置することはアプリケーションコード次第である。 もし必要であれば、はさむことが可能である。

    ブロードキャスタはいろんな状態変化をブロードキャストすることができ、 他のXULウィジェット中の属性の値に結びつけることができる。 より詳しいドキュメントについては[broadcasters.html ブロードキャスタとオブザーバ]を見ること。

    ウィンドウの例

    下記は完全なメニューバーとHTMLコンテンツエリアをもったウィンドウについての記述をした完全なXULドキュメントの例である。 メニューバーにはFileというメニューが1つあり、選択するとデバッグコンソールに"Hello World!"と書き出す メニューアイテムを1つもっている。 コンテンツエリアにはファイル contentframe.htmlの内容を表示する。このコードは本ドキュメントでは明確には触れていないような 実際のアプリケーションでのウィンドウを作る際に役にたついくつかの概念を紹介している。詳細はリンクに従うこと。 

    <?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/xul.css" type="text/css"?>
<!DOCTYPE window>
<window id="main-window" xmlns:html="https://www.w3.org/1999/xhtml"
        xmlns="https://www.mozilla.org/keymaster/gat...re.is.only.xul">
  <menubar>
      <menu name="File">
        <menuitem name="Hello World!" onclick="dump('Hello world!\n');"/>
      </menu>
  </menubar>
  <html:iframe id="content-frame" src="contentframe.html" flex="100%"/>
</window>

    この例の最初からwindowタグまでは標準に準拠した[#preamble プリアンブル]である。

    この例のwindowタグにはidが付与してあることに注意。厳密言うと、この例では必要ないものである。 しかしながら実用上、XULのほとんどのノードはこのような限定子をもっており、これがあるとAOMの <tt>getElementById</tt>メソッドを利用しての検索が簡単になる。 限定子は他にもXUL中の個々のエレメントに対しHTMLエレメントと同じ#文法を使って同じルールが適用できるのでCSSにも役にたつ。 

    #main-window {
  display: block;
  width: 100%;
  height: 100%;
}

    例えば、上記のスタイルルールはメインウィンドウに当てはまる。 ウィンドウがその中にコンテンツエリアを幅と高さをいっぱいいっぱいに取るように指定している。

    例の中の次のエレメントはメニューバーの宣言をしている。そのメニューバーには "File"というメニューが1つある。このメニューにはメニューアイテムが1つ あり、簡単なJavaScript onclickハンドラがメニューアイテムに張り付けられている。 このハンドラはメニューがユーザに選択されたときに発火し、デバッグ用コンソールに "Hello world!" のテキストをダンプする。(詳細は[menus.html メニューバーとメニュー]を参照のこと)。

    最後にHTML iframeがある.frameはhtml:の接頭辞を伴うことに注意。 これはframeがHTMLオブジェクトであり,デフォルトのXULネームスペースの中で使われているからである。 grameには他にもflexという特別の属性がある.これはどれだけのframeがウィンドウ中の領域に 引き伸ばすことができるかを示している(詳細については[boxes.html ボックスシステム]を参照のこと)。

    理想的な将来の方向性

    理想的にはXUL UI記述のパッケージは以下のような1つのファイルとして出荷されるのが望ましい: 

    <?xml version="1.0"?>
<?xml-stylesheet href="xul.css" type="text/css"?>
<!DOCTYPE package>
<package xmlns="https://www.mozilla.org/keymaster/gat...re.is.only.xul">
  <window id="main">
    ...
  </window>
  <window id="help">
    ...
  </window>
</package>

    そしてウィンドウ(あるいは他のサービス)は最初にパッケージ全体をパージングして、次にその結果得られた内容からウィンドウ に関する情報を取り出してインスタンス化される、というのが望ましい。 

    Package *package = LoadPackage("https://xxx/package.xul");
InstantiateWindow(package, GetNodeWithID("main");


    この素晴らしい仕組みは今はまだ動かない。というのはコードがXMLドキュメントをパージングした結果が ウィンドウであることを期待するからである。よって現在はXULファイルには少なくとも1つのウィンドウを含んでいなくてはならない。 

    <?xml version="1.0"?>
<?xml-stylesheet href="xul.css" type="text/css"?>
<!DOCTYPE window>
<window xmlns="https://www.mozilla.org/keymaster/gat...re.is.only.xul">
  ...
</window>

    我々は将来、さらに多くの"パッケージ"を実装していきたいと思う。

    国際化

    実用上の理由により,UI記述についてのロケールに依存した属性はローカライズの対象となる 特定の部分だけのUI記述のサブセットを記述したローカライズ個別のファイルでもっとも楽しんで 開発された(そして、おそらく配布されるであろう)。それはローカライズされた文字列の個々のファイルである。

    国際化についてはXULコーディングスタイルガイドライン のドキュメントの中でもっと詳細に議論されている。手短に言って、Mozillaはそのメカニズムとして XMLエンティティを採用した。 エンティティはその言語の1機能であり、したがって本文書の扱う範疇を越えている。XULファイルはロケールに 応じて変化するコンテンツを代わりに利用することで簡単にローカライズが可能である。 ローカライズされたテキストは別のDTD か、あるいはDTDの断片で定義されていなければならない。システム全体は個となったロケール独自のDTDによって設定 され、そのDTDは実行時にその時のロケールの設定にしたがって所定のXMLファイルによって選択される。 Mozillaはこの選択をローカライズされたXMLファイルがそのDTDを指定していれば XULのローカライズに関して で概説されているように chrome URLを用いて自動的に行う。

    ドキュメントのタグと貢献者

    タグ: 
     このページの貢献者: Taken, Mgjbot
     最終更新者: Taken,