ただし、Ext GWTとGWTの統合は依然として望まれていません。実際、Ext GWTの2番目のバージョンは、GWTインターフェイスをコンパイルするすべての手段に完全に取って代わり、イベント処理を含むすべての独自のAPIを提供します。 したがって、ライブラリの3番目のバージョン（ 開発者プレビューとして利用可能）では、Sencha開発者はGWTが採用したパターンとイディオムを使用してExt JSスクリプトの遺産を積極的に書き換えています。 予想される主な利点は、GWTとのより正確な統合であり、その結果、よりコンパクトで最適化されたインターフェイスコードです。JavaScriptおよびCSSは、遅延バインディングメカニズムを使用してGWTコンパイルの段階で生成および難読化されます。現在のプロジェクト。
外観を使用してウィジェットを実装する
GWTから採用されたパターンの1つにAppearanceがありました。これにより、ウィジェット、そのレイアウト、スタイル、および接続ロジックを独立した交換可能なパーツに選択できます。 このアプローチにより、ウィジェットのスタイルとテーマを簡単に変更することができ、さらにはレイアウトも変更できます。たとえば、divまたはbuttonをボタンのDOM実装として使用できます。 テキストとアイコンを変更できる単純なdivボタンにAppearanceパターンを適用する最も簡単な例は次のとおりです。
public interface Appearance { void render(SafeHtmlBuilder sb); void onUpdateText(XElement parent, String text); void onUpdateIcon(XElement parent, Image icon); } public static class DefaultAppearance implements Appearance { public interface Style extends CssResource { String testButton(); String testButtonText(); String testButtonImage(); } public interface Resources extends ClientBundle { @Source("DefaultAppearance.css") Style style(); } public interface Template extends XTemplates { @XTemplate(source = "DefaultAppearance.html") SafeHtml template(Style style); } private final Style style; private final Template template; public DefaultAppearance() { this((Resources) GWT.create(Resources.class)); } public DefaultAppearance(Resources resources) { this.style = resources.style(); this.style.ensureInjected(); this.template = GWT.create(Template.class); } @Override public void onUpdateIcon(XElement parent, Image icon) { XElement element = parent.selectNode("." + style.testButtonImage()); element.removeChildren(); element.appendChild(icon.getElement()); } @Override public void onUpdateText(XElement parent, String text) { parent.selectNode("." + style.testButtonText()).setInnerText(text); } @Override public void render(SafeHtmlBuilder sb) { sb.append(template.template(style)); } }
ネストされたStyleインターフェースは、コンポーネントのレンダリングスタイルを表します。 デフォルトでは、外部ファイルDefaultAppearance.cssにリンクします-この接続は、リソースインターフェイスで設定されます。 最後に、3番目のネストされたインターフェイスTemplateは、コンポーネントのレイアウトを表し、デフォルトで外部ファイルDefaultAppearance.htmlに接続されます。 DefaultAppearanceオブジェクトのコンストラクターで、Resourcesインターフェイスの実装をオーバーライドして、コンポーネントのスタイルまたはテーマを置き換えることができます。 同様に、テンプレートテンプレート、またはDefaultAppearanceオブジェクト全体を変更することもできます。ウィジェットは、単純なAppearanceインターフェイスを知っていれば、パラメータの設定やイベントの処理を委任できます。
その結果、Ext GWTは、CSSスタイル、HTMLマークアップを変更するか、AppearanceオブジェクトとDOMと相互作用してウィジェットをレンダリングするメカニズムを完全に再定義することにより、ウィジェットの表示に影響を与えることができる3つの拡張ポイントを提供します。 外観パターンのおかげで、これらすべての側面は互いにきちんと分離されています。
データモデルとしてのJavaBeanオブジェクト
最後に、ModelDataインターフェイスを放棄することができます。ModelDataインターフェイスでは、JavaBeanオブジェクトをデータモデルとして使用できるように、以前にラップする必要がありました。 ストアとローダーでは、インターフェイスコントラクトによって接続されておらず、特殊なクラスを拡張しないオブジェクトを使用できるようになる場合があります。 これはすべて、遅延バインディングマジックによって実現されます。オブジェクトの特定のフィールドにアクセスするためのコードは、GWTコンパイルの段階で生成されます。 これまでのところ、リポジトリとブートローダーを操作するための新しいAPIの例はありませんが、この革新は別の革新の例-再設計されたXTemplateテンプレートエンジンによって実証されています：
interface TemplateTest extends XTemplates { @XTemplate("<div><span>{name}</span></div>") SafeHtml renderCustomer(Customer customer); @XTemplate(source="template.html") SafeHtml renderCustomerExternal(Customer customer); } ... TemplateTest template = GWT.create(TemplateTest.class); SafeHtml html = template.renderCustomer(customer);
転送されたオブジェクトのフィールドは、テンプレートの本文で直接使用できるようになりました。たとえば、上記のコードではcustomer.nameフィールドが使用されます。 このコードをテストするために、メタインターフェースを宣言する必要さえありませんでした。必要なものはすべて、コンパイル段階で魔法のように生成されます。 例からわかるように、テンプレート自体は、XTemplateアノテーションの値文字列、または同じアノテーションのソースフィールドに名前が置かれている外部ファイルのいずれかに含めることができます。 テンプレートを使用した結果は、安全なHTMLです。受信したSafeHtmlが、送信されたフィールドと値でXSS攻撃の可能性のあるソースを正確に処理するという意味で安全です。
UiBinder：宣言的なインターフェイスレイアウト
もう1つの待望の機能は、GWT 2.0の既存のXMLマークアップメカニズムであるUiBinderとの統合です。 これにより、コンポーネントのレイアウトを外部XMLファイルに抽出し、宣言および構造化して、Javaコードで規定されているインターフェースロジックから分離することができます。 これまで、UiBinderは標準のGWTウィジェットとコンテナでのみ利用可能でしたが、現在ではExt GWT開発者は独自のコンポーネントを統合することに積極的に取り組んでいます。 APIがまだ完全に修正されておらず、別のjarファイルに移動されていないことによる主な問題は、LayoutDataを使用してコンテナーを構成することの難しさです-UiBinderの現在の実装では、XMLマークアップ属性用の独自のパーサーを作成できません。 Ext GWTとGWTの開発者は現在、これを可能にするGWTの変更を調整するプロセスにあります。 これまでのところ、次のオプションが提案されています（読みやすくするためにルートタグは省略されています）。
<border:BorderLayoutContainer pixelSize="800, 400"> <border:north layoutData="size:100; margins: 0 0 5 0"> <gxt:ContentPanel /> </border:north> <border:west layoutData="size:150; margins: 0 5 0 0"> <gxt:ContentPanel /> </border:west> <border:center layoutData="0"> <gxt:ContentPanel heading="BorderLayout UiBinder Example" /> </border:center> <border:east layoutData="size:150; margins: 0 0 0 5"> <gxt:ContentPanel /> </border:east> <border:south layoutData="size:100; margins: 5 0 0 0"> <gxt:ContentPanel /> </border:south> </border:BorderLayoutContainer>
提案されているlayoutDataフィールドの構文は、属性のCSSスタイルをやや連想させるものであることがわかります。 このメカニズムが機能するには、gxt-uibinder-3.0.0-SNAPSHOT.jarおよびuibinder-bridge-2.3.0-SNAPSHOT.jarライブラリーをプロジェクトに接続する必要があります。 しかし、私は与えられた例をテストすることができなかったと言わなければなりません-GWTは頑固に、未知のlayoutDataコンテンツをBorderLayoutDataオブジェクトに変換することを拒否しました。
おわりに
新しいバージョンのライブラリには、次のようなその他のマイナーな設備が含まれます。
- GWTと統合されたイベント処理メカニズム-リスナーなし、標準ハンドラー。
- FlashからJavaScriptに翻訳されたチャート-配布パッケージで利用可能なExt GWT Explorerアプリケーションの例は、いつものように、その流麗さとスピードに感心します。
- コンテナとレイアウトのいくつかの簡素化-LayoutContainerコンテナは、レイアウトレイアウト（RowLayoutContainer、BorderLayoutContainerなど）と密接に関連するようになりました。これにより、構成が多少簡素化され、一般的なセキュリティが提供されます。
結論として、Ext GWT 3.0の現在のバージョンはGWT 2.3.0と連携して動作し、コンパイルを成功させるには少なくともJava 1.6を必要としますが、これもGWT自体の要件によるものです。 ライブラリのルートパッケージも変更されました。最近のcom.extjsのブランド変更の精神で、com.senchaに置き換えられました。 開発者は数週間に1度、開発者プレビューの新しいバージョンをリリースすることを約束しますが、これらのバージョンは新しい機能とまだ修正されていないAPIのみを示しているため、開発での使用は推奨されません。