ExtJs4学习（九）读写器reader、writer

来源：互联网发布：java 文字转图片编辑：程序博客网时间：2024/05/16 05:45

Ext.data.reader.Json

JSON Reader是用一个代理来读取服务端响应的JSON格式的返回值. 一般用于将结果加载成一个存储集-例如我们将创建一些如下东西：

Ext.define('User', {    extend: 'Ext.data.Model',    fields: ['id', 'name', 'email']});var store = Ext.create('Ext.data.Store', {    model: 'User',    proxy: {        type: 'ajax',        url : 'users.json',        reader: {            type: 'json'        }    }});

以上示例创建了一个“User”模型.

我们创建了尽可能最简单类型的JSON Reader对象，简洁的告知了Store中的Proxy我们需要返回一个JSON Reader. Store将自动存储模型的配置，这样我们就可以通过以下方式来替代了：

reader: {    type : 'json',    model: 'User'}

我们设置的reader属性已准备好从服务端读取数据了- 同时它将接受一个如下响应：

[    {        "id": 1,        "name": "Ed Spencer",        "email": "ed@sencha.com"    },    {        "id": 2,        "name": "Abe Elias",        "email": "abe@sencha.com"    }]

读取其他JSON格式

如果你已经有了一份JSON格式的定义，且其看起来不是十分像以上我们提供的那些, 你仍然可以通过JsonReader的夫妻配置选项来使其可以解析你的格式. 例如，我们可以使用root配置来解析返回的如下数据:

{    "users": [       {           "id": 1,           "name": "Ed Spencer",           "email": "ed@sencha.com"       },       {           "id": 2,           "name": "Abe Elias",           "email": "abe@sencha.com"       }    ]}

为了解析这个，我们只要传递一个root配置匹配以上的“users”：

reader: {    type: 'json',    root: 'users'}

有时候JSON的结构异常复杂. 像CouchDB的文档数据库经常围绕这样一个嵌套的结构内每个记录提供元数据:

{    "total": 122,    "offset": 0,    "users": [        {            "id": "ed-spencer-1",            "value": 1,            "user": {                "id": 1,                "name": "Ed Spencer",                "email": "ed@sencha.com"            }        }    ]}

以上示例中的记录数据是在"users"数组中嵌套的一个额外级别，其中的每个“user”项目中都包含有额外元数据（例如本例中的’id‘和‘value’）. 为了解析以上json数据中的每个‘user’项中的数据，需要特别指定record配置，如下所示：

reader: {    type  : 'json',    root  : 'users',    record: 'user'}

响应的元数据

服务端可以在其响应中返回元数据，除了记录数据，其中数据本身的描述数据的属性集或用于重新配置的读取器。为了在响应中获取元数据，需要给响应数据的根简明加上一个‘metaData’属性. 元数据属性可以包含任何东西，但若Reader存在，其还支持的一个特定设置属性。:

root: 响应中包含记录数据的节点对应的根属性名称
idProperty: 数据中的主键字段属性名
totalProperty: 数据中的所有记录数属性名
successProperty: 响应中成功状态属性名
messageProperty: 一个可选的响应信息的属性名
fields: 在将响应数据转换成records之前用于重新配置Model的字段集的配置

一份Reader初始化的配置包含大概如下的这些属性 ("fields" 一般包含在Model的定义中，故这边不显示):

reader: {    type : 'json',    root : 'root',    idProperty     : 'id',    totalProperty  : 'total',    successProperty: 'success',    messageProperty: 'message'}

若要得到一个响应对象包含一个不同于以上初始化中定义的属性，需要使用‘metaData’属性动态重配置Reader。例如：

{    "count": 1,    "ok": true,    "msg": "Users found",    "users": [{        "userId": 123,        "name": "Ed Spencer",        "email": "ed@sencha.com"    }],    "metaData": {        "root": "users",        "idProperty": 'userId',        "totalProperty": 'count',        "successProperty": 'ok',        "messageProperty": 'msg'    }}

你可以放置任何的你需要的任意数据在‘metaData’属性中，Reader将忽略这些属性，但可以通过Reader的metaData属性（该属性也是通过监听Proxy'smetachange事件）。（当然也可以由 store替代）。然后，应用程序代码就可以选择任何的方式来处理获取到的元数据了。

如何使用这些来给Model定做合适的字段集的一个简单例子就是表格（grid）了。通过传递‘fields’属性，Reader内部会自动更新Model，但这些变化不会自动反应在grid内部，除非你已更新了列配置项. 你可以手动执行这些，或者通过一个标准的grid配置对象column 作为‘metaData’属性，然后就可以直接管理grid. 这有一个非常简单的例子说明如何实现这种情况:

// 响应格式:{    ...    "metaData": {        "fields": [            { "name": "userId", "type": "int" },            { "name": "name", "type": "string" },            { "name": "birthday", "type": "date", "dateFormat": "Y-j-m" },        ],        "columns": [            { "text": "User ID", "dataIndex": "userId", "width": 40 },            { "text": "User Name", "dataIndex": "name", "flex": 1 },            { "text": "Birthday", "dataIndex": "birthday", "flex": 1, "format": 'Y-j-m', "xtype": "datecolumn" }        ]    }}

Reader可以自动读取meta字段集的配置，并根据新的字段集重建Model，但要处理新的列配置，需要在应用程序代码中处理元数据。处理元数据时间可以很简单的通过store或proxy，例如：

    var store = Ext.create('Ext.data.Store', {        ...        listeners: {            'metachange': function(store, meta) {                myGrid.reconfigure(store, meta.columns);            }        }    });

Ext.data.reader.Xml

XML Reader 用于代理读取服务端返回的XML格式的响应. 这一般发生在加载Store的结果上 - 例如如下我们创建一个类似的:

Ext.define('User', {    extend: 'Ext.data.Model',    fields: ['id', 'name', 'email']});var store = Ext.create('Ext.data.Store', {    model: 'User',    proxy: {        type: 'ajax',        url : 'users.xml',        reader: {            type: 'xml',            record: 'user',            root: 'users'        }    }});

以上例子创建了一个'User'模型. 若不熟悉模型，可参阅Model文档，有详细的解释说明

尽可能以简单的方式告知Store的{@linkExt.data.proxy.Proxy Proxy} 我们需要一个XML Reader来创建一个极简单的XML类型的Reader, Store将自动传递模型的参数给Store 所以我们可以如下方式传递参数代替:

reader: {    type : 'xml',    model: 'User',    record: 'user',    root: 'users'}

以上我们设置好的reader已准备好从服务端读取数据 - 在这时，reader会接收到一个如下响应:

<?xml version="1.0" encoding="UTF-8"?><users>    <user>        <id>1</id>        <name>Ed Spencer</name>        <email>ed@sencha.com</email>    </user>    <user>        <id>2</id>        <name>Abe Elias</name>        <email>abe@sencha.com</email>    </user></users>

首先root 选项用于定义根节点<users> (一个完善的XML文档必须只有一个根). 然后XML Reader使用配置项record将数据拉成每个记录 - 在本例中，我们设置记录为‘user’, 所以以上的每个<user>都会转化成User模型中的对象.

注意：XmlReader不关心根节点root 和 record 元素是否嵌套在一个更大的结构内，所以如下的响应数据，仍然是可以有效工作的:

<?xml version="1.0" encoding="UTF-8"?><deeply>    <nested>        <xml>            <users>                <user>                    <id>1</id>                    <name>Ed Spencer</name>                    <email>ed@sencha.com</email>                </user>                <user>                    <id>2</id>                    <name>Abe Elias</name>                    <email>abe@sencha.com</email>                </user>            </users>        </xml>    </nested></deeply>

响应的元数据

服务器可以在响应中返回额外的数据, 例如记录集数和响应成功状态. 它们一般是如下这般包含在XML的响应中:

<?xml version="1.0" encoding="UTF-8"?><users>    <total>100</total>    <success>true</success>    <user>        <id>1</id>        <name>Ed Spencer</name>        <email>ed@sencha.com</email>    </user>    <user>        <id>2</id>        <name>Abe Elias</name>        <email>abe@sencha.com</email>    </user></users>

如果这些属性都存在于XML的响应中，他们可以被XmlReader解析到和加载它的Store使用。我们可以由指定的最后一对配置项来设立这些属性的名称：

reader: {    type: 'xml',    root: 'users',    totalProperty  : 'total',    successProperty: 'success'}

这些最后的配置项对于创建Reader工作不是必需的，但也可以是有用的。当服务端需要报告一个错误，或者用于表明有大量数据可用，其中正在返回的只有一个子集。

响应格式

注意: 为了浏览器能解析返回的XML文档, HTTP响应中的Content-Type header必须设为"text/xml" 或"application/xml"。这点非常重要 - 否则XmlReader将无法正常工作

0 0