Seth Lemmons：使用棒極了的Awesome Font

Ext JS 6附帶了一個新的海衛(wèi)一主題，可以使用Font Awesome字體作為背景圖像的圖標。不過，你知道如何通過“iconCls”和“glyph”來使用哪些相同的圖標(以及更多來自于廣泛的Font Awesome庫)嗎?

使用海衛(wèi)一主題的時候

可以在諸如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網(wǎng)站內(nèi)找到。

注意：“glyph”和“iconCls”配置項是互斥的。“glyph”配置項是在Ext JS 4.2中加入的，主要是解決EI6或7不支持偽元素這種情況。我們建議使用“iconCls”，而不是“glphy”，原因是Ext JS 5以上版本(只支持IE 8以上版本)所支持的瀏覽器都已經(jīng)支持偽元素。最現(xiàn)代的圖標字體已經(jīng)都會有一套CSS規(guī)則使用偽元素來將圖標應用到元素。

對于Ext.Img組件，可以通過使用autoEl配置項來封裝元素，兵使用cls或glyph來實現(xiàn)：

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。

不使用海衛(wèi)一主題的時候

如果不使用海衛(wèi)一主題，但又想在組件中使用Font Awesome圖標，可以在Sencha Cmd創(chuàng)建的應用程序中加入Font Awesome包。要實現(xiàn)這個，編輯“應用程序根目錄/app.json”文件，在requires數(shù)組內(nèi)加入以下代碼：

"requires": [

"font-awesome"

],

這樣就可以像使用海衛(wèi)一主題那樣直接在組件中使用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字體包指南。

查看主題指南可以了解更多有關海衛(wèi)一主題以及字體圖標的信息。

Joel Watson：保存關聯(lián)數(shù)據(jù)的另一選項

在Ext JS 5應用程序中使用關聯(lián)的時候，有許多方式可以用來保存關聯(lián)的數(shù)據(jù)。無論是喜歡保存每一個單獨的個體模型實例、創(chuàng)建一個自定義的Ext.data.writer.Writer實現(xiàn)，還是使用Ext.data.Session來創(chuàng)建批處理，Ext JS都提供了極大的靈活性以便你以最適合你的應用程序的的方式處理數(shù)據(jù)。

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

這些配置項允許你在模型數(shù)據(jù)將要被發(fā)送到服務器時，去定義傳遞給Ext.data.Model的getData方法的選項。allDataOptions用于phantom(新)記錄(或在writeAllFields為true的時候)，而partialDataOptions則用于其他方面(或writeAllFields為false的時候)。

這樣對關聯(lián)數(shù)據(jù)有什么好處呢?

下面來看兩個實體，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具有一對一關聯(lián)，因而在保存User的時候(無論是創(chuàng)建一個新用戶還是保存已修改過的已有用戶)，同樣需要在同一請求中發(fā)送任何關聯(lián)的Address數(shù)據(jù)。

在Ext JS 4，處理這一情況需要通過創(chuàng)建自定義的Ext.data.writer.Writer來擴展getRecordData方法以調(diào)用Ext.data.Model.getAssociatedData并添加關聯(lián)數(shù)據(jù)到請求數(shù)據(jù)中。雖然該方式在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模型數(shù)據(jù)在發(fā)送到服務器前的預處理方式：

persist: true ->只發(fā)送持續(xù)性字段(該屬性默認值為true)。

associated: true ->包含關聯(lián)數(shù)據(jù)

對于partialDataOptions，原理是一樣的，用來指定已存在的用戶模型數(shù)據(jù)發(fā)送到服務器前的預處理方式：

changes: true -> 只包含修改過的字段(默認)

critical: true -> 始終包含“關鍵”字段，而不管是否已被更改(默認)

associated: true -> 包含關聯(lián)數(shù)據(jù)

當然，可以根據(jù)應用程序的需要調(diào)整這些配置項。不過，問題的關鍵是，在應用程序內(nèi)創(chuàng)建或更新用戶時，發(fā)送到服務器的請求將包含任何關聯(lián)的數(shù)據(jù)，這太棒了。

有關詳細信息，請查看Fiddle中User和Address模型的創(chuàng)建和更新示例。

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

在Ext JS 5，一個相當大的變化是id的生成。在Ext JS 4，默認的id的生成器不會根據(jù)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();

在調(diào)用save發(fā)送請求到服務器的時候，會看到如下請求：

{

age:52,

firstName: "John",

lastName: "Doe"}

然而，在Ext JS 5，如果未提供id值，默認的id生成器會根據(jù)idProperty生成一個值，對于以上示例代碼，處理結果會不同：

{

id:"User-1",

age: 52,

firstName: "John",

lastName: "Doe"}

要注意，id(idProperty的默認值)現(xiàn)在被包含在請求中。在某些情況下，開發(fā)人員可能會在服務器端代碼中依賴Ext JS 4的行為來確定如何處理傳入的請求，在這種情況下，在Ext JS 5中的這種改變可能會引起一些沖突。

幸運的是，有許多選項可以用來處理(或左右)這種改變。

ID生成器

第一個選項(并且可能是最好的一個)是使用Ext JS中的id生成器，例如，使用Ext.data.identifier.Negative，該id生成器會產(chǎn)生連續(xù)的、值為負數(shù)的客戶端id值。在大多數(shù)的服務器端，id值是基于整數(shù)并是順序增加的，而由Ext.data.identifier.Negative產(chǎn)生的臨時id值，則很容易辨析，這樣，服務器代碼就可以很輕松的確定這是新的還是已有的Ext JS模型數(shù)據(jù)。

以上使用負數(shù)標識符的示例的處理結果可能會像以下代碼：

{

id:-1,

age: 52,

firstName: "John",

lastName: "Doe"}

當然，如果這個都不能滿足你的需求，你可以通過擴展Ext.data.identifier.Generator來創(chuàng)建自己的生成器。

clientIdProperty

如果使用id生成器不符合應用程序的需求，另一個選擇就是使用已被添加到Ext.data.writer.Writer的clientIdProperty配置項。使用該配置項，就可以在創(chuàng)建一個新記錄并發(fā)送數(shù)據(jù)到服務器時指定一個名字作為idProperty值的關鍵字：

Ext.define('User', {

extend: 'Ext.data.Model',

fields: ['firstName', 'lastName', 'age'],

proxy: {

type: 'rest',

url: 'user.json',

writer: {

type: 'json',

clientIdProperty: 'userId'

}

}

})

在保存用戶實例的時候，發(fā)送到服務器的數(shù)據(jù)會類似以下代碼：

{

"userId": "User-1",

"firstName": "John",

"lastName": "Doe",

"age": 52}

對于現(xiàn)有的服務器代碼依賴于id來標識新記錄的方式，該方式可保持現(xiàn)狀，不需要修改邏輯。

transform()

最后一個選擇是在代理的writer中指定一個自定義的transform方法。transform方法需要兩個參數(shù)“data”和“request”，并預期要返回發(fā)送到服務器的數(shù)據(jù)對象：

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，可以在發(fā)送請求之前做任何所需的數(shù)據(jù)處理(例如，移除id屬性)。這三個選項，為發(fā)送到服務器的數(shù)據(jù)內(nèi)容提供了最大的控制。不過，這會增加數(shù)據(jù)錯誤的風險，因而，使用需謹慎。

有關Ext JS 5中數(shù)據(jù)模型的改變和改進的更多信息，請參閱Ext JS升級指南。

總結

以上是生活随笔為你收集整理的ext get id js_【翻译】Ext JS最新技巧——2015-8-11的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。