私は通常、クラス構成オプションでできるだけ多くの構成を行うことを提唱します。これは、読みやすく、サブクラスでオーバーライドしやすいためです。それに加えて、将来、Sencha Cmd がコンパイラを最適化する可能性が高いため、コードを宣言型に保つと、最適化の恩恵を受ける可能性があります。
比較:
Ext.define('MyPanel', {
extend: 'Ext.grid.Panel',
initComponent: function() {
this.callParent();
this.store = new Ext.data.Store({
fields: [ ... ],
proxy: {
type: 'direct',
directFn: Direct.Store.getData
}
});
this.foo = 'bar';
}
});
...
var panel = new MyPanel();
と:
Ext.define('MyPanel', {
extend: 'Ext.grid.Panel',
alias: 'widget.mypanel',
foo: 'bar',
store: {
fields: [ ... ],
proxy: {
type: 'direct',
directFn: 'Direct.Store.getData'
}
}
});
...
var panel = Ext.widget({
xtype: 'mypanel',
foo: 'baz'
});
これらのアプローチが非常に異なることに注意してください。最初の例では、オブジェクトのプロパティ値、ストア構成、使用時の MyPanel クラス名など、多くの部分をハードコーディングしています。クラスは拡張不可能になるため、クラスのアイデアを事実上殺しています。2 番目の例では、おそらく異なる構成で何度も再利用できるテンプレートを作成しています。基本的に、それがクラス システム全体の目的です。
しかし、実際の違いはもっと深いところにあります。最初のケースでは、実質的に実行時までクラス構成を延期していますが、2 番目のケースでは、クラス構成を定義し、それを非常に明確に異なる段階で適用しています。実際、2 番目のアプローチは、JavaScript にネイティブに欠けているもの、つまりコンパイル時のフェーズを導入していると簡単に言えます。また、フレームワークのコード自体で活用される多くの可能性を提供してくれます。いくつかの例が必要な場合はExt.app.Controller
、Ext.app.Application
最新の 4.2 ベータ版をご覧ください。
より実用的な観点からは、2 番目のアプローチの方が読みやすく、扱いやすいため、より優れています。アイデアを理解すると、すべてのコードをそのように書いていることに気付くでしょう。この方法の方が簡単だからです。
このように考えてみてください: 古いスタイルの Web アプリケーションを作成し、サーバー側で HTML などを生成する場合、コードに HTML を混在させないようにしますよね? 左がテンプレート、右がコード。これは、データをハードコーディングするのと実質的に同じですinitComponent
。確かに、ある程度までは機能します。その後、スパゲッティのボウルになり、維持と拡張が困難になります。ああ、それをすべてテストしてください!うん。
現在、クラス定義時とは対照的に、実行時にインスタンスで何かを行う必要がある場合があります。古典的な例は、イベントリスナーの適用、またはコントローラーの呼び出しです。オブジェクト インスタンスから実際の関数参照を取得する必要があり、それをまたはで行う必要があります。ただし、この問題の緩和に取り組んでいます。これらすべてをハードコーディングする必要はありません。すでに文字列リスナー名をサポートしており、MVC もまもなくサポートされます。control
initComponent
init
Observable.on()
上記のコメントで述べたように、ドキュメントの記事またはガイドを作成して説明する必要があります。おそらく、4.2 がリリースされるまで待つ必要があります。それまでの間、この回答が問題を明らかにするはずです。