J'ai l'habitude de plaider pour avoir autant de la configuration que possible dans la classe d'options de configuration, car il se lit mieux et est plus facile à remplacer dans les sous-classes. En outre, il est fort possible qu'à l'avenir, Sencha Cmd ont compilateur optimisant donc, si vous gardez votre code déclaratif, il a pu bénéficier d'optimisations.
Comparer:
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();
Et:
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'
});
Notez comment ces approches sont très différentes. Dans le premier exemple, nous allons coder en dur beaucoup: propriété de l'objet de valeurs, magasin de configuration, MyPanel nom de la classe quand il est utilisé; nous sommes pratiquement tuer l'idée d'une classe, car il devient inextensible. Dans le deuxième exemple, nous sommes en train de créer un modèle qui peut être réutilisé de nombreuses fois, avec peut-être différente de la configuration, à la base, c'est ce que l'ensemble du système de classe est d'environ.
Cependant, la véritable différence se situe au plus profond. Dans le premier cas, nous sommes différant de la classe de configuration jusqu'à l'exécution, tandis que dans le second cas, nous avons la définition de la classe de configuration et l'application à très distinctement les différentes phases. En fait, nous pouvons facilement dire que la deuxième approche introduit quelque chose de JavaScript manque nativement: la compilation de phase. Et il nous donne une multitude de possibilités qui sont exploitées dans le cadre du code lui-même; si vous voulez quelques exemples, prendre un coup d'oeil à l' Ext.app.Controller et Ext.app.Application dans le dernier 4.2 beta.
De plus point de vue pratique, la deuxième approche est la meilleure parce que c'est plus facile à lire et traiter les. Une fois que vous avez saisi l'idée, vous trouverez vous-même écrit tout votre code comme ça, parce que c'est juste plus facile de cette façon.
Regardons cela de cette façon: si vous écrivez un style ancien de l'application Web, la génération de code HTML et des trucs sur le côté serveur, vous essayez de ne pas avoir un mélange de HTML avec le code, le feriez-vous? Les modèles de la gauche, du code de la droite. C'est pratiquement la même que coder en dur les données en initComponent: assurer qu'il fonctionne, jusqu'à un certain point. Puis il devient un bol de spaghetti, difficile à maintenir et à étendre. Oh, et de tester tout ça! Beurk.
Maintenant, il y sont des moments où vous devez faire quelque chose avec une instance au moment de l'exécution, par opposition à une définition de classe de l'époque - l'exemple classique est l'application des écouteurs d'événement, ou en appelant control chez les Contrôleurs. Vous aurez à prendre une fonction réelle des références à partir de l'instance de l'objet, et vous devez le faire dans initComponent ou init. Cependant, nous travaillons sur l'assouplissement ce problème - là ne devrait pas être dur obligation de coder en dur tout cela; Observable.on() prend déjà en charge de la chaîne de l'auditeur noms et MVC choses vont trop peu de temps.
Comme je l'ai dit dans les commentaires ci-dessus, je vais écrire un article ou un guide pour les docs, expliquer les choses. Qui aurait probablement attendre jusqu'à 4.2 est sorti; en attendant cette réponse devrait jeter une certaine lumière sur la question, je l'espère.
