From Learn About the Ext JavaScript Library

主要な変更点の要約

2.0の新しくなった点の概要は以下のとおりです。但し注意してください。1.xから2.0ではフレームワーク全体として無数の細かい改善やバグ修正などが入っています。その全てをリストにするのは不可能なので、こちらの概要ではアーキテクチャが変更になった分野や、全く新しい機能が加わった分野など、変更のあった主要な分野に焦点を当てています。それぞれの項目についての詳細な説明については、この概要の後の説で触れます。

• コンポーネントモデル
  Component クラスと BoxComponent クラスとは1.xでも存在しましたが、フレームワークを全体を通じて完全に統合されたものではありませんでした。2.0ではこれら二つのクラスはともに大きく改善され、今では全ての主要な部品(component)の基底をなすようになりました。これらクラスは開発者に殆ど見えないように意図して設計されていますが、2.0での部品ライフサイクルを理解することはExtスキルを次のレベルに高めるためには必須となります。 詳細はこちら
• コンテナモデル
  他の部品(component)を包含(contain)することができるウィジェットやレイアウトとして、いくつかのコアとなるクラスがあります。Containerは部品を包含してレイアウトするための基礎的な枠組みを提供するもので、Extの視覚的なフレームワーク全体にとって本質的に不可欠なものです。Panelはアプリケーション固有のUI機能の基礎を提供するためContainerを拡張したもので、おそらく部品クラス階層の中で最も重要なクラスといえるでしょう。Windowは特殊な種類のPanelで、真のデスクトップスタイルWebアプリケーションを実現するものです。Viewportは全画面ブラウザウィンドウを使ったWebアプリケーションを実装するために特に設計されたユーティリティコンテナです。 詳細はこちら
• レイアウト
  1.xではレイアウトはBorderLayoutやその関連クラスを中心としたものでしたが、2.0では新しいコンテナとレイアウトクラス群に基づくレイアウトアーキテクチャ全体が作られました。BorderLayout には今や9個のレイアウトスタイルの仲間が加わり、クラス階層は最大限の拡張性が実現できるよう再設計されました。また2.0ではレイアウトはより良く管理されたものとなり、1.1で複雑なレイアウトを実装したときに開発者が体験したような複雑さの一部は取り除かれました。 詳細はこちら
• グリッド
  グリッド部品は常にExtの中で中心となるウィジェットのひとつでしたが、2.0版でもその進化を続けています。この版(version)で新しくなった点として、さらに磨かれたユーザインターフェース、性能の改善、行のグルーピング、要約行、展開可能な行や行番号などをはじめとする様々な機能を提供する実例カスタムプラグインが挙げられます。 詳細はこちら
• XTemplate
  1.1のTemplateクラスは簡単なテンプレートでは大きな働きをしましたが、より高度な出力を生成するための鍵となるいくつかのフィーチャを欠いていました。2.0では新しいXTemplateクラスが追加されました。これはサブテンプレート、配列プロセシング、インラインコード実行、条件分岐、その他多くの機能を提供するものです。 詳細はこちら
• DataView
  1.1でViewクラスは、データのカスタマイズされたＵＩビューを生成するため、テンプレート化されたデータバインディングを提供しました。JsonViewはテンプレートをJSONデータに簡単に紐付けることができるヘルパークラスでした。2.0ではDataViewによってViewの能力は次のレベルに進みました。DataViewはBoxComponentを継承するためレイアウトに簡単に追加することができ、また新しいXTemplateクラスをサポートするためよりパワフルなテンプレート処理が可能となっています。詳細はこちら
• 他の新しい部品
  新しい部品やウィジェットが2.0で追加されました。これらにはAction、CycleButton、 Hidden (field)、 ProgressBar や TimeFieldなどがあります。 詳細はこちら

補注

• テーマ
  追加設定なしですぐに使えるテーマのサポートは2.0ではすこし簡素化されました。 Extは 1.xでは四つの異なるテーマをサポートしていましたが、 2.0ではその数は二つに減りました。("Ext Blue" と Gray). カスタムのテーマは、Grayテーマのスタイルシートを実装例として使うことで簡単に追加することができますし、新しい 2.0 コミュニティ　テーマ がすでに利用可能となっています. これはAPI変更ではありませんが、ここで言及するに値する特筆すべき変更といえます。
• 非互換な変更
  残念なことに, 2.0には1.xへの後方互換を保つことができなかった変更がいくつかあります。基礎となる部品と描画のモデルが大幅に変更となったため、既存部品のいくつかは1.xでの対応部品と根本的に非互換なやりかたでの書き直しが必要でした。願わくば既存のExt 1.xアプリケーションをアップグレードする上での重荷を和らげることができるよう、1.x から 2.0 へのマイグレーションガイドを提供しております。

コンポーネントモデル

Component 概要

2.0でのひとつの目標として、以前よりもさらに基礎的な構成ブロックを提供することがありました。Component クラスはもとももと1.xで導入されましたが、 フレームワーク全体を通して完全に統一性のとれたものではありませんでした。2.0でComponentの能力は遥かに拡大・改良され、結果としてアーキテクチャ全体でも最も基礎となるクラスのひとつとなっています。Componentは部品の生成、描画、イベントハンドリング、状態管理、破棄にわたって統一的なモデルを提供し、これら特性を必要とするすべてのExt部品はComponentを継承するようになっています。2.0でのComponentの鍵となる特長は以下のとおりです：

• 明示的なコンストラクタのチェーンとオーバーライド
  Component はそれ自身、いかなる設定もサブクラスに渡す基本コンストラクタを持っています。またクラス階層のそれぞれのステップでカスタムのコンストラクタロジックを提供するため、すべての継承連鎖を通じて initComponent関数を使うことができます。サブクラスではどんな設定も適切に適用されるということを安全に想定することができ、またinitComponentで必要となる全ての初期化コードを実装すべきです。
• 管理された描画
  2.0では、すべての部品は自動的に遅延（オンデマンド）描画をサポートすることとなり、そして描画パイプラインは開発者のために自動で管理されます。たとえそうだとしても、beforerenderとrender イベントを通して、開発者は描画プロセスをカスタマイズするための究極の柔軟性をなお保持することができます。
• 管理された破棄
  全ての部品には destroy 関数が含まれており、Extは部品がもう不要となったとき自動でガーベージ収集と破棄をすることで、後片付けの管理をします。もちろんオブジェクト破棄にはbeforedestroy と destroy イベントが用意されており、必要に応じてこれを使って取り扱うことができます。
• 自動状態管理
  Componentには状態を設定したり取り出したりする機能が組み込まれました。state Providerを使ってグローバルなStateManagerを初期化すれば多くのExtの部品(component)は自動状態管理をサポートします。
• 基本的な部品の振る舞いに対する一貫したインタフェース
  例えば、隠す(hide)、表示する(show)、有効化する(enable)、無効化する(disable)といった、全ての部品に適用できる最も基礎的なふるまいは、Componentクラスを通じて提供されます。これらは全て必要に応じてオーバーライドしたりサブクラスでカスタマイズしたりすることができます。
• ComponentMgr経由で参照可能
  全てのExt部品は生成時にComponentMgrに登録されるので、単にExt.getCmp('id')を呼ぶだけでいつでもこれを取り出すことができます。
• プラグインサポート
  どんな部品(component)もプラグインを使って拡張することが出来るようになりました。プラグインというのは、Ext.Component型のひとつの引数を受け取るinitメソッドをもつ任意のクラスです。プラグインは plugins 設定オプションを通じて任意のComponentに追加することができます。部品が生成されるとき、部品は、もしプラグインがひとつまたは複数指定されていれば、それぞれの initメソッドを呼び出して自身の参照を渡します。それぞれのプラグインは、そこで必要に応じてComponentのメソッドを呼んだりイベントに対応したりして、プラグインの機能を提供します。

Component のライフサイクル

一般的にいえば、2.0のComponentアーキテクチャは"普通に動き"ます。殆どの部品(component)管理を末端開発者には透過的に扱えるよう設計されています。しかし、何かをカスタマイズしたりComponentを拡張する必要が出てくる時がきっと来ます。それがComponenetのライフサイクルの完全な理解が役に立つ時です。Componentを基にした全てのクラスのライフサイクルにおける最も重要な局面は以下のとおりです：

初期化

1. configオブジェクトが提供される
   Componentを継承するクラスは　それぞれのコンストラクタをつくる必要はありません。（また大抵は作るべきではありません。）Componentのコンストラクタはサブクラスに渡された設定を適用するだけでなく、以下全てのステップを提供します。
2. 基本的な Componentイベントが生成される
   これらはどんなComponentからも発火されるイベントで、具体的にはenable, disable, beforeshow, show, beforehide, hide, beforerender, render, beforedestroy, destroyです。(完全な詳細については Component API docs をご覧ください)
3. ComponentMgrに登録される
   そのため部品は常にExt.getCmp経由で参照可能です。
4. initComponentメソッドが呼ばれる
   サブクラスにとって、ここが最も重要な初期化ステップです。というのは、initComponentは、サブクラスごとに必要なコンストラクタロジックを提供するために実装されるべく意図された、テンプレートメソッドだからです。生成するクラスを先頭にComponentクラスまで継承階層を遡りながら、それぞれのクラスでsuperclass.initComponentを呼ぶことが期待されています。このメソッドがあるおかげでクラス階層のどのステップのコンストラクタロジックでも、簡単に実装したり必要に応じてオーバーライドしたりすることができます。
5. Stateが初期化される (該当する場合)
   もしComponentが状態を意識するものであり、かつその状態が取得可能ならば、状態がリロードされます。
6. プラグインがロードされる (該当する場合)
   もしこのComponentに設定で何らかのプラグインが指定されていれば、ここでプラグインが初期化されます。
7. componentが描画される (該当する場合)
   renderToかapplyTo が設定されているときは、部品は直ちに描画されます。そうでないときは描画はComponentがコード上で明示的に表示指示されたり、部品を包含するコンテナに描画しろと言われるまで描画を遅らせます。

描画

1. beforerenderイベントが発火する
   これは取消可能なイベントで、任意のハンドラに必要に応じてComponentに描画をさせないようにすることを可能とするものです。
2. containerがセットされる
   もしコンテナが指定されていなければ、ComponentのDOM要素の親ノードがコンテナとして指定されます。
3. onRenderメソッドが呼ばれる
   サブクラスにとって、ここが最も重要な描画ステップです。というのは、onRenderは、サブクラスごとに必要な描画ロジックを提供するために実装されるべく意図された、テンプレートメソッドだからです。生成するクラスを先頭にComponentクラスまで継承階層を遡りながら、それぞれのクラスでsuperclass.onRenderを呼ぶことが期待されています。このメソッドがあるおかげでクラス階層のどのステップの描画ロジックでも、簡単に実装したり必要に応じてオーバーライドしたりすることができます。
4. Component が"非隠蔽化"される
   デフォルトでは多くの部品は"x-hidden"といった特別なCSSクラスを使って隠されています。もしautoShow設定値がtrueであると、ここで部品からあらゆる"hide"クラス指定が取り除かれます。
5. カスタムの class と/または style が適用される
   すべてのComponentのサブクラスは特別な設定属性であるcls と style をサポートします。これらはカスタムでユーザ定義のそれぞれCSSクラスとルールで、このComponentの基底となるDOM要素に適用されます。Componentとそれを構成する部品を視覚的にカスタマイズするには、cls値を指定するほうが好ましい方法です。ここで指定するクラスはComponentをマークアップする最上位のラッパ要素に提供されるため、Componentのいかなる下位要素も標準CSSの継承ルールを使って調整可能です。
6. renderイベントが発火する
   これはComponentがこの時点での描画に成功したという通知です。開発者はこの時点でDOM要素が必要に応じて自分のコードから参照可能になったと安全に想定することができます。もし描画に先立ってComponentにアクセスしようとすると、それは参照不能でありエラーを受け取ることとなります。
7. afterRenderメソッドが呼ばれる
   サブクラスで必要になるかもしれない特別な描画後ロジックを提供するために実装したりオーバーライドするためのテンプレートメソッドです。それぞれのサブクラスはsuperclass.afterRenderを呼ぶことが期待されています。
8. Componentが隠され(hide) かつ／または 無効化（disable）される (該当する場合)
   hiddenとdisabledの設定値はここで適用されます。
9. state固有のイベントが初期化される (該当する場合)
   状態を意識するComponentは状態をロードしたりセーブしたりするために必要な特別なイベントを宣言することができます。もし設定されれば、そのようなイベントが追加されます。

破棄

1. beforedestroy イベントが発火する
   これは取消可能なイベントで、任意のハンドラに必要に応じてComponentに破棄をさせないようにすることを可能とするものです。
2. beforeDestroy メソッドが呼ばれる
   サブクラスで必要になるかもしれない特別な破棄前ロジックを提供するために実装したりオーバーライドするためのテンプレートメソッドです。それぞれのサブクラスはsuperclass.beforeDestroyを呼ぶことが期待されています。
3. 要素(Element)とそのリスナが除去される
   もしComponentが描画されている場合は、まずその基底のDOM要素のイベントリスナが削除され、次に要素そのものがDOMからさ駆除されます。
4. onDestroy メソッドが呼ばれる
   サブクラスで必要になるかもしれない特別な破棄後ロジックを提供するために実装したりオーバーライドするためのテンプレートメソッドです。それぞれのサブクラスはsuperclass.onDestroyを呼ぶことが期待されています。注 Containerクラス（とそのあらゆるサブクラス）はonDestroyのデフォルト実装を持っていて、そこで自動的に自分のitemsコレクションをループして子Componentに対して再帰的にdestroyを呼び出しています。
5. ComponentがComponentMgrから登録解除される
   Ext.getCmp経由での参照ができなくなります。
6. destroy イベントが発火する
   これはComponentがこの時点で正しく破棄され、DOMで参照できなくなったことを知らせる単純な通知です。
7. Componentのイベントリスナが除去される
   Componentはそれ自身、基底にあるDOM要素とは別にイベントリスナを持つことができます。もしそのようなイベントリスナがあれば削除されます。

部品のxType

2.0の新しい概念としてxtypes（Ext固有部品type）が挙げられます。使用可能な xtypesの一覧が Component クラス APIのヘッダ部に要約してあります。 xTypes は普通のJavaScript object typeと似た感じで使うことができ、isXType や getXTypeといったメソッドを使って部品の種類を調べたり比較したりすることがきます。また getXTypesを使って任意のComponentのxtype階層を一覧することもできます。

しかしXTypeの本当の力は、Componentの作成と描画を最適化するのに使われる「方法」のところにあります。どんなComponentでもxtypeを特定した設定オブジェクトとしてこれを、実際にオブジェクトとしてインスタンス化することなく、それを宣言して描画パイプラインに渡す形で暗黙的に生成することができます。描画を遅らせるだけでなく、オブジェクト自体が実際に生成されるタイミングも遅らせられるため、Componentが実際に必要となるまでメモリとリソースの消費を抑えることができます。多数のComponentを包含した複雑でネストされたレイアウトでは、これはなかなかの性能改善となります。

//包含された部品を明示的に作成:
var panel = new Ext.Panel({
   ...
   items: [
      new Ext.Button({
         text: 'OK'
      })
   ]
};
 
//xtypeを使って暗黙的に作成:
var panel = new Ext.Panel({
   ...
   items: [{
      xtype: 'button',
      text: 'OK'
   }]
};

最初の例では、常にボタンはパネルが初期化される間に直ちに生成されます。Componentをたくさん使う場合は、このアプローチでは潜在的にページ描画を遅くさせてしまいます。 二つ目の例では、パネルがブラウザに実際に表示されるまではボタンは生成も描画もされません。もしパネルが表示されない場合（例えば、隠されたままのタブなど）ボタンは決して作成されず、いかなるリソースも決して消費しません。

BoxComponent

2.0での新しい話ではないですが、BoxComponent は、Componentを拡張したこれまた重要な基礎クラスで、これは視覚的に描画されてレイアウトに参加するあらゆる部品(component)に対して、整合性の取れたクロスブラウザのボックスモデル実装を提供するものです。BoxComponent は透過的にサイズ・位置を扱い、自動的にpadding、margin、borderのブラウザ固有の違いを処理して、全てのサポートブラウザ間で整合性の取れたボックスモデルを実現しています。2.0では全てのContainerクラスはBoxComponentを継承しています。

コンテナモデル

Container

Container は他の部品（Component）を格納するあらゆる部品の最も基本的な基礎となるもので、レイアウトと他部品のネストやサイズ調整を扱うのに必要な描画ロジックを提供します。また、整合性をもってContainerに部品を追加ための基本的なメカニズムも提供します。Containerクラスは決して直接的に使う必要はなく、全ての視覚的なコンテナ部品の基底クラスとして意図されたものです。

Panel

Panel は2.0ではとても働き者なcontainerで、おそらくあなたがしたいレイアウト作業の90％で使うものとなるでしょう。その最も基本にあるのは、レイアウトを構築するにあたって、Panelが完全に非視覚的な箱として振舞うことができることです。しかし一方で、PanelはアプリＵＩウインドウの基本的な構成要素を提供するという側面もあります。その中には、ツールバーやメニューを追加するための上下のバーや、ヘッダ・フッタ・本体といったものも含まれます。また、Panelは開いたり閉じたりするビルトインの振る舞いやツールボタン、また他の多様なツールのためのあらかじめ組み込まれたボタン群も提供します。PanelはあらゆるContainerまたはlayoutの中に簡単にドロップすることができ、そのときのレイアウトや描画ロジックは完全にExtが管理します。

以下の Panel サブクラスは Ext 2.0の主要なWidgetです:

• GridPanel
• TabPanel
• TreePanel
• FormPanel

Window

Window は、フロートさせたり、最大化/最小化したり、復元したり、ドラッグしたり、とできるよう機能特化したパネルです。これは、Ext Desktop Demo.にみられるようなデスクトップ風ウィンドウアプリケーションＵＩの基礎クラスとして使ってもらうことを意図しています。

Viewport

Viewport はdocument bodyを自動的にレンダーして、自分自身をブラウザのviewportの大きさに合わせるユーティリティContainerクラスです。ブラウザのリサイズやレイアウト再計算を自動でやってくれるので、全画面アプリケーションを作る際の便利なショートカットとなります。ただし注意してください。Viewportオブジェクトはdocument.body以外のいかなるcontainerにもレンダーできませんし、それゆえ1ページに1つのインスタンスしか使うことはできません。

レイアウト

はじめに

1.x のBorderLayoutは魅力的なＵＩを極めて簡単に作成することを可能としていた一方、真にカスタマイズされたレイアウトを作成することを可能にするのに充分な構成要素を提供はしていませんでした。複雑なレイアウトの作成にはスクロールバーやネストの問題、その他変わった振る舞いなどを巧く扱うため手作りのコーディングが必要でした。

Ext 2.0 では完全に見直されたエンタプライズレベルのレイアウト管理システムを実現しました。10個の分離したレイアウトマネージャが、殆どどんなスタイルのアプリケーションレイアウトでも作れる基礎を提供するようになりました。また、サイズや位置、スクロールその他属性が何も設定せずにすぐに普通に期待されたとおり動くよう、レイアウトはExtで管理されています。互いに異なるレイアウトを持った、異なる種類のコンテナを組み合わせたり、好きなだけネストさせるようなことも簡単です。

Layoutは new キーワードで直接作るように意図されたものではありません。レイアウトはContainerクラスによって内部的に生成され使われるものです。すべてのContainerはそれ自身レイアウトのことは何も知りません。Containerは単に設定時に特定された何がしかのレイアウトクラスにレイアウトの仕事を移譲します。Containerをつくるときはどんなときでも、そのレイアウトスタイルを決めることができ、またその対応するレイアウトクラスに設定できるオプションをlayoutConfig属性を通じて設定できます。例えば：

var panel = new Panel({
    title: 'My Accordion',
    layout: 'accordion',  // このパネルで使うレイアウトスタイル
    layoutConfig: {
        animate: true     // このレイアウト専用の設定値をここに書く
    }
    // 追加の Panel オプション...
});

またこれを理解しておくことも重要です。ネストしたレイアウトをつくるとき、パネルが他のPanelを包含していたとしたら、そのレイアウトの中の全てのPanelにレイアウトを指定しておく必要があります。'border'や'accordion'のような特別なレイアウトを必要としないようなときは、ほとんどの場合たぶん'fit'を指定すればいいでしょう。なぜなら、'fit'でもPanelとしての基本的なサイズ調整管理をコンテナとの間でしてくれるからです。もしレイアウトを指定しないと、それでもアプリケーションが動くようデフォルトのContainerLayoutクラスが設定されます。しかし、実際のほとんどのケースでは、明示的なレイアウトなしでは結果としての振る舞いは期待したものと異なるもとのなってしまうでしょう。

各種レイアウトクラスは、それぞれそれ自身に特化した設定オプションをサポートしています。詳しくはAPI docsを参照してください。

各種レイアウトマネージャ

	ContainerLayout 他の全てのレイアウトマネージャの基底クラスで、特にレイアウトが定義されなかったときのcontainerオブジェクトのデフォルトレイアウトとなるものです。ContainerLayoutは視覚表現をまったく持ちません。即ち単に包含されたitem群を管理し、必要に応じてそれらを描画したりリサイズバッファリングなどの基本的な作業をこなすだけです。ContainerLayoutは一般的には直接作成されるべきものではありませんが、カスタムのレイアウトを作成する場合はこのクラスを拡張して使うこともできます。 API referenceをご覧ください。		CardLayout CardLayoutは、あるコンテナが複数の要素を保持しているものの、常にただひとつだけの要素が見えるような場合に使うためのレイアウトです。よく使われるケースとしては、ウィザードやカスタムでのタブの実装、ないし複数の相互排他的なページから成る情報表示が必要なケースが挙げられます。 API referenceをご覧ください。
	AbsoluteLayout コンテナからの相対X/Y座標を通じて、包含された部品群を正確に配置することができるとてもシンプルなレイアウトです。 API referenceをご覧ください。		ColumnLayout マルチカラムフォーマットで構造的なレイアウトを作成するための選択肢となるフォーマットです。即ち、それぞれの列の幅がパーセントまたはピクセル単位で指定できる一方、高さは内容に応じて変化することが許されます。API referenceをご覧ください。
	AccordionLayout AccordionLayoutは、内容表示のために開いたり閉じたりするパネルを垂直に積み上げたセットを包含します。一度に開くことができるパネルはただひとつです。 API referenceをご覧ください。		FitLayout 単一の部品を、コンテナの大きさにぴったり正確にフィットさせるシンプルなレイアウトスタイルです。他に特に必要なレイアウトスタイルがない場合、FitLayoutはたいていコンテナの中で使うのにデフォルトとしてもっとも適したレイアウトです。 API referenceをご覧ください。
	AnchorLayout このレイアウトはコンテナの両側の縁（へり）から相対的に要素をアンカーするためのものです。アンカーする要素はパーセント比率か両縁からのオフセット値でアンカーすることができます。また実際のコンテナとは異なるサイズの仮想的なレイアウトキャンバスも実現することができます。 API referenceをご覧ください。		FormLayout FormLayout は、特にデータ入力フォームを作るために設計されたユーティリティレイアウトです。特に注意すべきなのは、一般的には、普通のPanelに layout:'form'と指定したものよりは、おそらくFormPanelを使うのがよいということです。なぜなら、FormPanelであれば自動的にフォーム提出を扱う部分も提供するためです。FormPanelはlayout:'form'を使わなくてはならず（これは変更不可能です）追加的なレイアウトスタイルが必要なフォームをつくるときは、ネストしたPanelを用いる必要があります。 API referenceをご覧ください。
	BorderLayout これは、1.xでのBorderLayoutとまったく同じもので、レイアウト領域はネストやパネルのスライド（開いているものも閉じているものも）、それに、領域を隔離するスプリッタをビルトインでサポートします。典型的なビジネスアプリでの主要なＵＩを担う最も広く使われるレイアウトスタイルです。 API referenceをご覧ください。		TableLayout このレイアウトスタイルは列と行をまたがることができる標準のＨＴＭＬテーブル表記を生成します。 API referenceをご覧ください。

グリッド

概説

グリッドUIは実際にはGridViewクラスで実装されており2.0でGridViewは大きく改良されました。2.0のGridViewに含まれる主要な新しい特長は以下のとおりです:

• 性能改良
  GridViewの基礎をなす構造と描画コードは2.0で性能を第一優先に完全にリファクタリングされました。その結果、列ロックの機能は取り除かれました。（次節参照）
• ルック＆フィールの改良
  2.0の新しいテーマとともにグリッドも整形手術され、以前にもましてより艶やかで、視覚的に魅力的になりました。
• 単一レベル行グルーピング
  複数の行をある列に関してグループ化したり、ユーザが動的に再グループ化できるようになりました。
• グループ概要行
  それぞれの行グループがそのグループ内のデータの要約をあらわす要約行をもつこともできます。
• 高度なプラグインサポート
  2.0ではプラグインサポート全般が新しくなっています。特にGridView は新しいプラグインアーキテクチャを用いて大きな効果を上げていて、例としてあらかじめ作られたいくつかのプラグインとともに出荷されています。RowExpanderプラグインは開いたり閉じたりする行を提供し、それぞれの行は貫通行を含むことができます。またRowNumbererプラグインはシンプルな行番号サポートを提供しています。

列ロックに関する注記

Ext 1.xで導入された列ロック機能が2.0でなくなり、サポートされなくなったことに気づく方もいるかも知れません。列ロックは一部の少数のユーザには役に立っていましたが、2.0のGridViewで実装された新しい機能の多く（例えばグルーピング、サマリ等）と互換性がなく、またロックをサポートするために必要なグリッド描画の方法が原因で（皆さんが求める）性能を劣化させてしまっていました。1.xのGridViewを2.0に移植したり、パッチで2.0のGridViewに列ロックをサポートさせたりすることも出来るかもしれませんが、Extチームが公式にこれを行うことはありません。

注: 現在コミュニティで列ロックを2.0向けユーザ拡張として実装する努力が進行中であり、本稿執筆時点においてすでにかなり期待できる状態に見えます。詳細はフォーラムスレッドで確認いただけます。

XTemplate

複雑なデータ構造を使った極めて堅牢なテンプレート処理をサポートするため、XTemplate は多様な組み込みのタグや特別な演算子を提供します。以下はサポートされる特長の大まかな一覧です。完全な詳細と利用例については、 XTemplate API docsを参照してください。

• 配列の自動補填とスコープ切り替え
• サブテンプレートスコープからの親オブジェクト参照
• 配列アイテムのインデックス変数
• データの値に対する基本的な math 演算サポート
• 平坦な配列の自動描画 (非オブジェクト値を含む)
• ifを用いた基本的な条件分岐
• テンプレート内の任意のインラインコード実行が可能
• template設定プロパティのサポート
• 設定オブジェクト経由のカスタムテンプレートメソッド

DataView

DataView は表面上は1.1のViewクラスにとても似たものです。どちらもテンプレート化したデータ描画をサポートし、どちらもデータストアに紐づき、またどちらも組み込みの選択モデルとイベント群を持っています。しかしDataViewは新しい2.0アーキテクチャのパワーの全てを活かせる点で大きな前進といえます。最も重要な変更は以下のとおり:

• BoxComponentを継承
  1.xのViewクラスはObservableを継承していました。これはつまり独立した部品として十分動く一方で、ほかの部品とともにレイアウトに収まる能力が組み込まれていないことを意味します。一方上記で触れたように、DataViewはBoxComponentを継承しています。 これはComponentのライフサイクル管理やBoxComponentとしてレイアウトが出来るなど多くの利点をもたらしています。
• XTemplateを活用
  1.x のViewクラスは1.xのTemplateクラスを内部的に使ってテンプレート処理をしていました。これは比較的シンプルなビューを扱うのには問題ありませんでしたが、複雑な描画タスクを扱うパワーには欠けていました。 前述のようにDataViewはテンプレート処理に2.0のXTemplateクラスを使います。これは遥かに強力なテンプレートエンジンを提供し、DataViewが複雑なデータを簡単にカスタムUIに描画することを可能にしています。
• 追加の設定オプション
  DataView は以下の新しい設定を使うことでさらに柔軟性を提供します:
  • itemSelector: DataViewはビューの中のそれぞれの項目を識別するためにDomQueryセレクタを使います。このことが1.xと比べたとき柔軟性とスピードを向上させています。
  • simpleSelect: これはユーザにシフトキーやコントロールキーを押させることなく複数項目を選択することでの複数選択を実現する新たな選択モードオプションです。
  • overClass: それぞれの要素に対して、mouseover時に自動的に適用され、mouseout時に除外されるCSSクラスです。
  • loadingText: DataView はstoreに紐づいた他のExt部品と同様の標準的なloading自動マスク機能をサポートします。

他の新しい部品

2.0では、いくつかの面白い新しい部品やウィジェットが追加されました。 それぞれの部品で何ができるのか、完全な詳細についてはAPIドキュメントをご覧ください。

Action

Actionは特定の部品から抽象化されうる再利用可能な機能の断片です。Actionを使うことでハンドラや設定オプションやUI更新をActionインターフェースをサポートするいかなるとも共有するこおとができます。（主にToolbar, Button, Menu 部品など）API Referenceをご覧ください。

CycleButton

これはCheckItem要素群からなるメニューを一つ包含する特別なSplitButtonの実装です。ボタンはクリックでそれぞれのメニュー項目を自動的にまわり、アクティブなメニュー項目に対してボタンのchangeイベントを発生させます。（また提供されていれば、ボタンのchangeHandler関数を呼び出します）FeedViewerデモアプリケーションの中で実例をご覧になれます。プレビューウィンドウの位置を指定するボタンがCycleButtonです。 API リファレンス

Hidden (field)

シンプルに、標準のHTML hidden 入力フィールドとしてレンダされる便利なフィールドです。 これはフォームで送信するhidden値を格納するのにとても便利で、2.0では、hiddenフィールドも他のExtフォーム部品と同様に生成したり操作することができるようになっています。 API リファレンスをご覧ください。

ProgressBar

1.xでも簡単なMessageBoxクラスの中にシンプルなプログレスバーが実装されていました。今回プログレスバーは独立したウィジェットに分離され、はるかに改良されました。 ProgressBarは２つの異なるモード(手動と自動)をサポートし、そのルック＆フィールは簡単にカスタマイズできます。API リファレンスをご覧ください。

TimeField

シンプルな time picker ドロップダウン実装です。 API Referenceをご覧ください。