【翻译】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升级指南。