ExtJSの概要4.旧バージョンでの移植体験

ExtJSフレームワークの4番目のバージョンが長い間リリースされているという事実にもかかわらず、ハブ上のこのバージョンにはあまり多くの資料がありません そして、第4バージョンでは、API、クラス構造、および提案されたアプリケーションアーキテクチャが大幅に再設計されていることを考慮すると、話をすることがあります。

この記事では、既存のコードベースを新しいバージョンに移植するというコンテキストで、フレームワークの印象を伝えようとします。 また、落とし穴や便利な（そしてそうではない）ヘルプページへのリンクも忘れないようにしましょう。

Ext4、うーん。 Ext3との下位互換性はなく、あらゆる種類の新しい方法論を課して「より簡単」にしています。 JavascriptフレームワークのWindows Vista

（ stackoverflow.comのコメントの1つ）

ExtJS 4は、以前のバージョンのフレームワークと互換性がありません。
つまり、フレームワークの他のバージョン用に作成されたアプリケーションは機能しません（些細な場合を除く）。 これは、次の理由で発生します。

1. 変更されたアプリケーションアーキテクチャ要件
2. クラス構造が変更されました
3. APIセマンティクスが部分的に変更されました

アプリケーションアーキテクチャ

最も重要な変更はアーキテクチャに関するものです。ExtJS4はクライアント側のMVCパターンを説きました。 コンポーネントのすべての「ビジネスロジック」を「コントローラー」の本質にし、視覚的なインターフェースを提供するものにする必要があります-「ビュー」（ビュー）を作成します。 データを操作するロジックは、「モデル」レイヤー（以前はExt.data.RecordおよびExt.data.Storeストレージと呼ばれていたExt.data.Model自体を直接参照する）に配置する必要があります。

実際、すべての視覚的なコンポーネント-パネル、テーブル、ツリーなど。 -これらは、代表またはその一部であることの申請者です。 視覚的なコンポーネントを埋め込む（集約する）機能は、ビューレベルでのみ可能になりました。実際、コントローラーはフラットレイヤーに存在します。

表現は、イベントのメカニズムによる状態の変化について「上向き」に報告します。
「ビジネスタスク」の観点から重要なイベントは、コントローラーで処理する必要があります。 これを行うために、各コントローラーにはマジックコントロール （）メソッドがあり、これを使用してビューの一部から発生するイベントをサブスクライブします。 コントローラーは、 ComponentQueryと呼ばれるCSSに似た構文を使用して、誰がイベントを受信したいかを伝えます 。

Ext.define('My.controller.Header', { extend: 'Ext.app.Controller', //... init: function() { this.control({ 'button[action=help-toggle]': { scope: this, click: this.toggleHelp }, 'mainmenuview': { scope: this, afterrender: this.menuRendered } } ); }, toggleHelp: function () { //some actions }, menuRendered: function () { //some other actions } } ); 

次のことを理解することが重要です。

1. 各コントローラーは使用可能なビューポート全体を 「見る」ため、多くの場合、非常に特定のソケットまたは完全に一意のボタンが必要なものを正確に指定する必要がありますが、これは必ずしも簡単ではありません。
2. control（）のパラメーターで記述されたComponentQueryは、イベント選択ルールであり、動的に動作します。 これは、ビューからのイベントについて、このハンドラーをコントローラーで呼び出すことができるかどうかをアプリケーションが決定することを意味します。

したがって、以前は簡単に再利用できる1つのコンポーネントにカプセル化されていたものが、「思考のない」表現のセット、モデルのセット、コントローラーのセットなど、いくつかの異なる部分に分割されるようになりました。 これは、静的に定義された要素を持つ小さなアプリケーションにとっては有利であり、動的なコンポーネントの作成を伴うページにとっては深刻な困難です（このような問題については、 こちらを参照してください ）。

クラスとコンポーネント

フレームワークの4番目のバージョンでは、標準クラスの構造が大幅に再設計されました。 クラス名自体がより簡潔になり、クラス間の職務分担がより思慮深くなりました。
たとえば、ストアのデータの読み取り/書き込みのロジックがExt.data.proxy.Proxyに実際にカプセル化されたことを嬉しく思いました （たとえば、以前のRESTfulサーバーでの作業を再定義するには、プロキシとリポジトリ自体の対応するメソッドの両方をオーバーラップする必要がありました） -メソッドonWrite、onRead、およびonUpdate）。
さらに、ストアがJSON（JsonStore）、XML（XmlStore）データで動作するか、テーブルのデータをグループ化できるか（GroupingStore）を選択する必要があり、これら3つのクラスがすべて1階層レベル。

場合によっては、オブジェクトの動作がより予測可能になりました。 そのため、コンポーネントが描画される前（「render」イベントの前）に、そのアイテムコレクションはMixedCollectionタイプであり、 以前のように配列ではなく（些細ですが素晴らしい）、Ext.grid.Panelテーブルはストレージを再起動した後に選択の損失を個別に処理しますこの状況は手動で記述する必要がありました）。

ExtJS 4は、標準JavaScriptクラスのプロトタイプを変更しません。
したがって、以前はプロトタイプを補完していた実用的な関数（Function。CreateDelegate（）、String。Format（）、Array。IndexOf（））は、別々のsynletton（Ext.Function。Bind（）、Ext.String。Format（ ）およびExt.Array。indexOf（）、それぞれ）。

APIの変更

ほとんどの場合、メソッド名もより簡潔になりましたが、実際には変更されています。 したがって、アプリケーション内のすべてが正しく機能していることを確認するために時間をかける必要があります。 たとえば、SelectionModelのselectionRow（）メソッドは、新しいselect（）と一致するようになりました。

不快なことから：リモートデータを操作するリポジトリを操作するセマンティクスは大きく変わりました。 サーバーに要求するためのパラメーターの追加セットを追加するための「ハンドル」がなくなったことが判明したとき、私は驚きました。 setBaseParam（）またはload（params）の類似物はもう提供されていません。
基礎となるProxyクラスは、以前と同様に任意のパラメーターセットを使用できますが、Storeレベルでは、Proxyに与えられる厳密に定義されたキーセットがあります。

UPDコメントは、実際に追加のパラメーターを渡すことができることを示唆しています（追加してくれたMrSLonoedに感謝します）。

明らかに、 setBaseParam （）ストアの代替として、いわゆるフィルターとソーター（フィルターとソーター）がサポートされています。 これらのエンティティは、ローカル（既存のデータセットで作業する）とリモート（パラメーターとしてサーバーに送信される）の両方で使用できます。 特徴：フィルターおよびソーターの場合、HTTPパラメーターへのシリアル化の柔軟な可能性はありません。 そのため、フィルターは常に次のようにシリアル化されます
mywebserver?{otherparams}&filters={your serialized filters}
{your serialized filters}行内でのみフィルターのシリアル化を制御できますが、標準の方法を使用すると、フィルターパラメーターを{your serialized filters}できません。

フィルターを使用してクエリにパラメーターを追加する方法の例を次に示します。

 Ext.define('My.proxy.Ajax', { extend: 'Ext.data.proxy.Ajax', alias: 'proxy.myajax', filterParam: '', getParams: function (params, operation) { params = this.callParent(arguments); var filters = operation.filters; if (this.filterParam === '' && filters && filters.length) { Ext.apply(params, this.encodeFilters(filters)) } return params; }, encodeFilters: function (filters) { var f, po = {}, i; for (i = 0; i < filters.length; ++i) { f = filters[i]; po[f.property] = f.value; } return po; } } ); 

UPD：重要な詳細に注意してください。デフォルトでは、追加されたフィルターはリモートとローカルの両方で機能します。 つまり、フィルター「q = myValue」を追加すると、このフィルターは対応するHTTPパラメーターにシリアル化されます（これは適切ですが）が、ロード後にストアに適用されます。 また、レコードがすべて受信されたときに、レコードが消失した原因を把握するには、長時間かかる場合があります。 したがって、Storeパラメーターを見てください。 filterOnLoad 。

2番目の不快な瞬間もAJAXに関連しています。 何らかの理由で、ExtJS4には、オブジェクトをHTTPキー値パラメーターのセットとして送信する単純なWriterケースがありません。 その実装は簡単ですが、「堆積物は残りました」：

 Ext.define('My.data.writer.Http', { extend: 'Ext.data.writer.Writer', alias : 'writer.http', writeRecords: function(request, data) { if (Ext.isArray(data)) { data = data[0]; } Ext.apply(request.params, data); return request; } } ); 

動的ローディング

このフレームワークの新しいバージョンは、JSリソース（クロスドメインを含む、さらにはfile://プロトコル-たとえば、ファイルシステムからHTMLファイルとしてヘルプを開くことができる）を動的にロードする機能を提供します。 この点で、各クラスでは、このクラスが依存するクラスまたはパッケージの名前を明示的に登録することをお勧めします。
これは、Ext.require（）を呼び出すか、クラス宣言の本体で同じ名前のセクションを使用することで実行されます。

ソースの読み込みが有効になっている場合、すべての依存関係が正しく考慮されるように、ExtJSはクラスグラフの正しい読み込みを保証します。
ファイルシステム内のソースコードの場所に関連する新しい要件は、この機能に関連しています：完全なクラス名は、ファイルシステム内のファイルの場所を一意に決定する必要があります（たとえば、JavaやPHPのZend Frameworkでの慣習です）。

ExtJSソースには、いくつかのオプションもあります。

• ext-all-debug.js
• ext-all-debug-w-comments.js
• ext-all-dev.js
• ext-all.js
• ext-debug.js
• ext-dev.js
• ext.js

名前にすべての接尾辞を含まないExt * .jsファイルは、動的ロードが有効になっているソースです。 このようなリソースは、デバッグモードでのみ使用する必要があります。
ところで、「誤って」有効にされた動的なリソースの読み込みは、読み込まれたリソースに構文エラーが含まれている場合の「サイレント」ExtJSクラッシュの別の原因です。 ただし、まだJSLintをキャンセルした人はいません。

ExtJSをリンクするための各オプションの目標については、 こちらをご覧ください 。

ソースを読み、優秀なプログラマーになりましょう！
ご清聴ありがとうございました。