Recherche…


Séparation des préoccupations

Pire

ViewController:

// ...
myMethod: function () {
    this.getView().lookup('myhappyfield').setValue(100);
}
//...

Vue:

//...
items: [
    {
        xtype: 'textfield',
        reference: 'myhappyfield'
    }
]
//...

Meilleur

ViewController:

// ...
myMethod: function () {
    this.getView().setHappiness(100);
}
//...

Vue:

//...
items: [
    {
        xtype: 'textfield',
        reference: 'myhappyfield'
    }
],
setHappiness: function (happiness) {
    this.lookup('myhappyfield').setValue(happiness);
}
//...

Explication

Dans cet exemple, les deux extraits de code effectuent la même tâche. Cependant, dans le cas où la référence à myhappyfield change ou la méthodologie de l'indication de «bonheur» change de manière significative, la première approche nécessite des changements à chaque endroit où la référence est utilisée.

Avec des préoccupations séparées (le dernier exemple), la vue fournit un moyen abstrait de modifier le «bonheur» que d'autres classes peuvent utiliser. L'interrogation et la manipulation des composants sont conservées à un endroit (juste à côté de la définition de la vue elle-même!) Et les appels à la méthode abstraite n'ont pas besoin d'être modifiés.

Bien qu'il soit possible pour un contrôleur d'autoriser l'interrogation à travers les couches d'une vue, il est fortement conseillé de faire un résumé de ce comportement dans les méthodes de la vue. De cette manière, une vue peut fournir aux autres classes des méthodes normalisées pour l’influencer et minimiser ou éliminer les modifications apportées aux autres classes lorsque la structure d’une vue change.

Étendre vs annuler

Remplace:

Remplacer le fichier:

Ext.define('MyApp.override.CornField',
    override: 'Ext.form.field.Text',
    initComponent: function () {
        this.callParent(arguments);
        this.setValue('Corn!');
    }
);

Utiliser dans l'application:

{
    xtype: 'textfield'
}

Extensions:

Remplacer le fichier:

Ext.define('MyApp.form.field.CornField',
    extend: 'Ext.form.field.Text',
    alias: 'widget.cornfield',
    initComponent: function () {
        this.callParent(arguments);
        this.setValue('Corn!');
    }
);

Utiliser dans l'application:

{
    xtype: 'cornfield'
}

Explication

ExtJS propose deux méthodes principales pour modifier le comportement des classes existantes: leur extension et leur remplacement. Chacun présente des avantages et des inconvénients à prendre en compte avant de les utiliser.

Les extensions

L'extension d'une classe crée une nouvelle classe qui hérite de son comportement et de sa configuration de son parent. En créant une nouvelle classe via l'extension, des modifications répétées de la configuration et du comportement peuvent être effectuées dans un emplacement central et réutilisées dans toute l'application. Le plus grand avantage de l'extension est que la classe parente reste intacte et disponible pour des cas d'utilisation plus simples où le comportement étendu n'est pas souhaité.

Les exemples de cas d'utilisation judicieux pour les extensions incluent des champs de formulaire personnalisés avec un comportement spécial, des modaux spécialisés et des composants personnalisés en général.

Remplace

Le remplacement d'une classe modifie le comportement d'une classe existante en place. La configuration et les méthodes dans les remplacements remplacent entièrement leurs homologues de la classe parente, en créant de nouvelles configurations par défaut et un comportement qui remplissent l'ensemble de l'application. Les dérogations doivent être utilisées avec parcimonie en raison de la nature destructive de leur utilisation. une classe étendue peut généralement offrir les mêmes avantages tout en laissant la classe des parents intacte.

Cependant, les dérogations peuvent apporter des avantages dans certaines situations. Les cas de bonne utilisation incluent la correction de bogues dans les classes existantes, la modification du comportement du proxy pour ajouter des informations supplémentaires aux requêtes, telles que des jetons ou des données de session, et un comportement spécifique sur une application.

Séparations distinctes des corrections de bogues

Dans ExtJS, vous pouvez remplacer presque toutes les méthodes du framework et le remplacer par le vôtre. Cela vous permet de modifier les classes existantes sans modifier directement le code source ExtJS.

Parfois, vous pouvez souhaiter améliorer une classe existante ou fournir une propriété par défaut saine pour une classe.

Par exemple, vous pouvez souhaiter que tous les champs de données de votre modèle autorisent les valeurs NULL.

Ext.define('MyApp.override.DataField', {
  override: 'Ext.data.field.Field',
  allowNull: true
});

Dans d'autres cas, vous devrez corriger quelque chose qui est cassé dans le cadre.

Voici un exemple de correction de bogue avec la documentation. Notez que le nom de classe contient "fix" plutôt que "override". Le nom actuel n'est pas important, mais la séparation est.

Ext.define('MyApp.fix.FieldBase', {
  override: 'Ext.form.field.Base',
  /**
   * Add a description of what this fix does.
   * Be sure to add URLs to important reference information!
   *
   * You can also include some of your own tags to help identify
   * when the problem started and what Sencha bug ticket it relates to.
   *
   * @extversion 5.1.1
   * @extbug EXTJS-15302
   */
  publishValue: function () {
    this.publishState('value', this.getValue());
  }
});

Maintenant, quand vient le temps de passer à la prochaine version d'ExtJS, il n'y a qu'un seul endroit où vous devez vérifier quels correctifs peuvent être supprimés.



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow