【翻譯】Ext JS最新技巧——2015-8-11

原文： Top Support Tips

Seth Lemmons：使用棒極了的Awesome Font

Ext JS 6附帶了一個新的海衛一主題。可以使用Font Awesome字體做爲背景圖像的圖標。只是。你知道怎樣經過「iconCls」和「glyph」來使用哪些一樣的圖標（以及不少其它來自於普遍的Font Awesome庫）嗎?

使用海衛一主題的時候

可以在諸如Ext.panel.Panel、Ext.menu.Item、Ext.button.Button等等組件中使用iconCls來設置Font Awesome字體爲圖標，語法例如如下：

// use ‘x-fa’ to add set the font family to Font Awesome // then use 「fa-{iconName}」 to set the icon itself iconCls: ‘x-fa fa-star’ // the icon will be the Star icon from Font Awesome

對於組件的「glyph」配置項，語法例如如下：

glyph: ‘xf005@FontAwesome’ // using the unicode 「f0005」 for Star

所有的Font Awesome圖標都可以在Font Awesome站點內找到。

注意：「glyph」和「iconCls」配置項是相互排斥的。「glyph」配置項是在Ext JS 4.2中增長的，主要是解決EI6或7不支持僞元素這樣的狀況。

咱們建議使用「iconCls」，而不是「glphy」，緣由是Ext JS 5以上版本號（僅僅支持IE 8以上版本號）所支持的瀏覽器都已經支持僞元素。

最現代的圖標字體已經都會有一套CSS規則使用僞元素來將圖標應用到元素。

對於Ext.Img組件，可以經過使用autoEl配置項來封裝元素，兵使用cls或glyph來實現：

Ext.create({ xtype: 'image', autoEl: 'div', cls: 'x-fa fa-star', //glyph: 'xf005@FontAwesome', alt: 'star', style: { fontSize: '36px', lineHeight: '36px' },
               height: 36,
               width: 36
         });

注意：對於Image的配置項，需要使用cls來取代iconCls。

不使用海衛一主題的時候

假設不使用海衛一主題，但又想在組件中使用Font Awesome圖標，可以在Sencha Cmd建立的應用程序中增長Font Awesome包。要實現這個，編輯「應用程序根文件夾/app.json」文件，在requires數組內增長下面代碼：

"requires": [
               "font-awesome"
        ],

這樣就可以像使用海衛一主題那樣直接在組件中使用iconCls配置項了。

Pictos圖標

還可以在app.json文件裏經過請求Picto來使用Picto圖標集：

"requires": [
               "font-pictos"
        ],

請求後，就可以使用下面iconCls語法來使用Picto庫的圖標了：

// pictos-{iconName} is used to set a named icon from the Pictos icon set iconCls: 'pictos pictos-home'

要了解Picto圖標的相應信息，可以查看Sencha字體包指南。

查看主題指南可以瞭解不少其它有關海衛一主題以及字體圖標的信息。

Joel Watson：保存關聯數據的還有一選項

在Ext JS 5應用程序中使用關聯的時候，有不少方式可以用來保存關聯的數據。不論是喜歡保存每一個單獨的個體模型實例、建立一個本身定義的Ext.data.writer.Writer實現，仍是使用Ext.data.Session來建立批處理，Ext JS都提供了極大的靈活性以便你以最適合你的應用程序的的方式處理數據。

只是。在Ext JS 5中， Ext.data.writer.Writer有幾個新的特性爲你提供了一種新選擇：allDataOptions和partialDataOptions。

這些配置項贊成你在模型數據將要被髮送到server時，去定義傳遞給Ext.data.Model的getData方法的選項。allDataOptions用於phantom（新）記錄（或在writeAllFields爲true的時候），而partialDataOptions則用於其它方面（或writeAllFields爲false的時候）。

這樣對關聯數據有什麼優勢呢?

下面來看兩個實體，User和Address：

Ext.define('User', {
    extend: 'Ext.data.Model',
    fields: ['firstName', 'lastName', 'age', {
        name: 'addressId',
        reference: 'Address',
        unique: true
    }],
    ...
});

Ext.define('Address', {
    extend: 'Ext.data.Model',
    fields: ['street', 'city', 'state', 'postalCode']
});

在演示樣例中，User與Address具備一對一關聯，於是在保存User的時候（不論是建立一個新用戶仍是保存已改動過的已實用戶），一樣需要在同一請求中發送不論什麼關聯的Address數據。

在Ext JS 4。處理這一狀況需要經過建立本身定義的Ext.data.writer.Writer來擴展getRecordData方法以調用Ext.data.Model.getAssociatedData並增長關聯數據到請求數據中。儘管該方式在Ext JS 5中也能很是好的工做，但可以利用allDataOptions和partialDataOptions來完畢一樣的事情。只是需要保存幾行代碼：

Ext.define('User', {
    extend: 'Ext.data.Model',
    fields: [...],
    proxy: {
        type: 'ajax',
        url: 'user.json’, writer: { type: 'json', allDataOptions: { persist: true, associated: true }, partialDataOptions: { changes: false, critical: true, associated: true } } } });

在allDataOptions配置項，指定了新建的User模型數據在發送到server前的預處理方式：

persist: true ->僅僅發送持續性字段（該屬性默認值爲true）。
associated: true ->包括關聯數據

對於partialDataOptions，原理是同樣的。用來指定已存在的用戶模型數據發送到server前的預處理方式：

changes: true -> 僅僅包括改動過的字段(默認)
critical: true -> 始終包括「關鍵」字段。而不論是否已被更改(默認)
associated: true -> 包括關聯數據

固然，可以依據應用程序的需要調整這些配置項。只是。問題的關鍵是，在應用程序內建立或更新用戶時。發送到server的請求將包括不論什麼關聯的數據，這太棒了。

有關具體信息。請查看Fiddle中User和Address模型的建立和更新演示樣例。

Joel Watson：在Ext JS 5中使用模型的Ids

在Ext JS 5，一個至關大的變化是id的生成。

在Ext JS 4。默認的id的生成器不會依據idProperty本身主動去生成值。好比。簡單的用戶模型演示樣例：

Ext.define('Fiddle.model.User', {
    extend: 'Ext.data.Model',
    fields: ['firstName', 'lastName', 'age'],
    proxy: {
        type: 'rest',
        url: 'user.json'
    }
});
// create a new User
var user = new Fiddle.model.User({
    firstName: 'John',
    lastName: 'Doe',
    age: 52
});
user.save();

在調用save發送請求到server的時候，會看到例如如下請求：

{ age: 52, firstName: "John", lastName: "Doe" }

然而，在Ext JS 5，假設未提供id值，默認的id生成器會依據idProperty生成一個值。對於以上演示樣例代碼，處理結果會不一樣：

{ id: "User-1", age: 52, firstName: "John", lastName: "Doe" }

要注意，id（idProperty的默認值）現在被包括在請求中。在某些狀況下，開發者可能會在server端代碼中依賴Ext JS 4的行爲來肯定怎樣處理傳入的請求，在這樣的狀況下，在Ext JS 5中的這樣的改變可能會引發一些衝突。

幸運的是，有不少選項可以用來處理（或左右）這樣的改變。

ID生成器

第一個選項（並且多是最好的一個）是使用Ext JS中的id生成器。好比，使用Ext.data.identifier.Negative。該id生成器會產生連續的、值爲負數的客戶端id值。

在大多數的server端，id值是基於整數並是順序增長的。而由Ext.data.identifier.Negative產生的暫時id值。則很是easy辨析，這樣，server代碼就可以很是輕鬆的肯定這是新的仍是已有的Ext JS模型數據。

以上使用負數標識符的演示樣例的處理結果可能會像下面代碼：

{ id: -1, age: 52, firstName: "John", lastName: "Doe" }

演示樣例：使用負數標識符：https://fiddle.sencha.com/#fiddle/p03

固然。假設這個都不能知足你的需求，你可以經過擴展Ext.data.identifier.Generator來建立本身的生成器。

clientIdProperty

假設使用id生成器不符合應用程序的需求。還有一個選擇就是使用已被增長到Ext.data.writer.Writer的clientIdProperty配置項。使用該配置項，就可以在建立一個新記錄併發送數據到server時指定一個名字做爲idProperty值的關鍵字：

Ext.define('User', {
    extend: 'Ext.data.Model',
    fields: ['firstName', 'lastName', 'age'],
    proxy: {
        type: 'rest',
        url: 'user.json',
        writer: {
            type: 'json',
            clientIdProperty: 'userId'
        }
    }
})

在保存用戶實例的時候，發送到server的數據會類似下面代碼：

{
    "userId": "User-1",
    "firstName": "John",
    "lastName": "Doe",
    "age": 52 }

對於現有的server代碼依賴於id來標識新記錄的方式，該方式可保持現狀。不需要改動邏輯。

演示樣例：使用clientIdProperty：https://fiddle.sencha.com/#fiddle/p02

transform()

最後一個選擇是在代理的writer中指定一個本身定義的transform方法。

transform方法需要兩個參數「data」和「request」。並預期要返回發送到server的數據對象：

writer: {
    type: 'json',
    transform: function(data, request) {
        // do any data transformations here
        // ...
        // return the data object that should be sent to server
        return data;
    }
}

使用transform，可以在發送請求以前作不論什麼所需的數據處理（好比。移除id屬性）。這三個選項。爲發送到server的數據內容提供了最大的控制。

只是，這會增長數據錯誤的風險，於是，使用需慎重。

演示樣例：使用transform：https://fiddle.sencha.com/#fiddle/p05

有關Ext JS 5中數據模型的改變和改進的不少其它信息，請參閱Ext JS升級指南。