Szukaj…


Rozdzielenie obaw

Gorzej

ViewController:

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

Widok:

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

Lepszy

ViewController:

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

Widok:

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

Wyjaśnienie

W tym przykładzie dwa fragmenty kodu wykonują to samo zadanie. Jednak w przypadku, gdy odniesienie do zmian w myhappyfield lub metodologia znacznego wskazania „szczęścia” zmieni się znacząco, poprzednie podejście wymaga zmian w każdym miejscu, w którym używane jest odniesienie.

Z oddzielnymi obawami (drugi przykład) widok zapewnia abstrakcyjny sposób modyfikowania „szczęścia”, z którego mogą korzystać inne klasy. Zapytania i manipulowanie komponentami są przechowywane w jednym miejscu (obok samej definicji widoku!), A wywołania metody abstrakcji nie muszą się zmieniać.

Chociaż kontroler może zezwolić na zapytania w dół przez warstwy widoku, zdecydowanie zaleca się wyodrębnienie tego zachowania na metody w widoku. W ten sposób widok może zapewnić znormalizowane sposoby wpływania na niego przez inne klasy oraz minimalizowania lub eliminowania zmian w innych klasach, gdy zmienia się struktura widoku.

Rozszerz vs Zastąp

Zastępuje:

Zastąp plik:

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

Użyj w aplikacji:

{
    xtype: 'textfield'
}

Rozszerzenia:

Zastąp plik:

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

Użyj w aplikacji:

{
    xtype: 'cornfield'
}

Wyjaśnienie

ExtJS zapewnia dwa główne sposoby zmiany zachowania istniejących klas: rozszerzanie ich i zastępowanie. Każda ma zalety i pułapki, które należy rozważyć przed ich użyciem.

Rozszerzenia

Rozszerzenie klasy tworzy nową klasę, która dziedziczy jej zachowanie i konfigurację po rodzicu. Tworząc nową klasę poprzez rozszerzenie, wielokrotne zmiany konfiguracji i zachowania można wprowadzać w centralnej lokalizacji i ponownie wykorzystywać w całej aplikacji. Największą zaletą rozszerzenia jest to, że klasa macierzysta pozostaje nienaruszona i dostępna dla prostszych przypadków użycia, w których przedłużone zachowanie nie jest pożądane.

Przykłady dobrych przypadków użycia rozszerzeń obejmują niestandardowe pola formularza ze specjalnym zachowaniem, wyspecjalizowane moduły i ogólnie niestandardowe komponenty.

Zastępuje

Przesłonięcie klasy modyfikuje zachowanie istniejącej klasy w miejscu. Konfiguracja i metody zastępowania całkowicie zastępują odpowiedniki klas nadrzędnych, tworząc nowe domyślne konfiguracje i zachowania, które pojawiają się w całej aplikacji. Zastąpienia powinny być stosowane oszczędnie ze względu na destrukcyjny charakter ich użycia; klasa rozszerzona może zazwyczaj zapewniać te same korzyści, pozostawiając klasę nadrzędną bez zakłóceń.

Jednak zastąpienia mogą przynieść korzyści w niektórych sytuacjach. Do dobrych przypadków użycia należą poprawianie błędów w istniejących klasach, modyfikowanie zachowania proxy w celu dołączania dodatkowych informacji do żądań, takich jak dane tokena lub sesji, i generalnie zmuszanie określonego zachowania do zachowania domyślnego w aplikacji.

Oddziel przesłonięcia od poprawek błędów

W ExtJS możesz zastąpić prawie każdą metodę frameworka i zastąpić ją własną. Pozwala to modyfikować istniejące klasy bez bezpośredniej modyfikacji kodu źródłowego ExtJS.

Czasami możesz ulepszyć istniejącą klasę lub zapewnić rozsądną domyślną właściwość klasy.

Na przykład możesz chcieć, aby wszystkie pola danych twojego modelu pozwalały na wartości null.

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

W innych przypadkach będziesz musiał naprawić coś, co jest zepsute w ramach.

Oto przykład poprawki błędu z dokumentacją. Zauważ, że nazwa klasy zawiera „fix” zamiast „override”. Rzeczywista nazwa nie jest ważna, ale separacja jest.

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

Teraz, gdy przychodzi czas na aktualizację do następnej wersji ExtJS, jest tylko jedno miejsce, w którym musisz sprawdzić, które poprawki można usunąć.



Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow