extjs
Insidie ​​comuni e best practice

Separazione degli interessi

Peggio

ViewController:

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

Vista:

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

Meglio

ViewController:

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

Vista:

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

Spiegazione

In questo esempio, i due snippet di codice eseguono la stessa operazione. Tuttavia, nel caso in cui il riferimento a myhappyfield cambi o la metodologia di indicazione di "felicità" cambi in modo significativo, l'approccio precedente richiede cambiamenti in ciascun punto in cui viene utilizzato il riferimento.

Con le preoccupazioni separate (l'ultimo esempio), la vista fornisce un modo astratto per modificare la "felicità" che altre classi possono utilizzare. L'interrogazione e la manipolazione dei componenti sono mantenute in un posto (proprio accanto alla definizione stessa della vista!) E le chiamate al metodo astratto non devono cambiare.

Sebbene sia possibile per un controller consentire l'interrogazione verso il basso attraverso i livelli di una vista, è fortemente consigliabile astrarre tale comportamento in metodi sulla vista. In questo modo, una vista può fornire modi standardizzati ad altre classi per influenzarla e minimizzare o eliminare le modifiche ad altre classi quando cambia la struttura di una vista.

Estendi vs Ignora

Sostituzioni:

Sostituisci file:

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

Usa in app:

{
    xtype: 'textfield'
}

estensioni:

Sostituisci file:

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

Usa in app:

{
    xtype: 'cornfield'
}

Spiegazione

ExtJS fornisce due modi principali per modificare il comportamento delle classi esistenti: estendendole e sovrascrivendole. Ognuno ha vantaggi e insidie ​​che dovrebbero essere considerati prima di usarli.

Estendere una classe crea una nuova classe che eredita il suo comportamento e la configurazione dal suo genitore. Creando una nuova classe tramite l'estensione, è possibile apportare modifiche di configurazione e comportamentali ripetute in una posizione centrale e riutilizzarle nell'intera applicazione. Il più grande vantaggio dell'estensione è che la classe genitore rimane intatta e disponibile per casi d'uso più semplici in cui il comportamento esteso non è desiderato.

Esempi di casi d'uso validi per le estensioni includono campi modulo personalizzati con comportamento speciale, modalit specializzati e componenti personalizzati in generale.

Sostituire una classe modifica il comportamento di una classe esistente sul posto. La configurazione e i metodi nelle sostituzioni sostituiscono completamente le controparti della classe genitrice, creando nuove configurazioni e comportamenti predefiniti che popolano l'intera applicazione. Gli override dovrebbero essere usati con parsimonia a causa della natura distruttiva del loro uso; una classe estesa può in genere fornire gli stessi benefici lasciando indisturbata la classe genitore.

Tuttavia, le sostituzioni possono fornire vantaggi in alcune situazioni. I buoni casi d'uso includono la correzione di bug nelle classi esistenti, la modifica del comportamento del proxy per aggiungere informazioni aggiuntive alle richieste, come un token o dati di sessione, e in genere forzare un comportamento specifico a essere il comportamento predefinito in un'applicazione.

Sostituzioni separate da correzioni di bug

In ExtJS, puoi sovrascrivere quasi tutti i metodi del framework e sostituirlo con il tuo. Ciò consente di modificare le classi esistenti senza modificare direttamente il codice sorgente ExtJS.

A volte, potresti voler migliorare una classe esistente o fornire una proprietà predefinita sana in una classe.

Ad esempio, è possibile che tutti i campi dei dati del modello consentano valori nulli.

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

In altri casi, dovrai correggere qualcosa che è rotto nel framework.

Ecco un esempio di una correzione di bug con la documentazione. Nota che il nome della classe contiene "fix" piuttosto che "override". Il nome effettivo non è importante, ma la separazione è.

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());
  }
});

Ora, quando arriva il momento di passare alla versione successiva di ExtJS, c'è solo una posizione da controllare per vedere quali delle correzioni dei bug possono essere rimosse.