边学边写Ext--Grid

用ext有一段时间,为了更速度的完成任务,稍微的探讨下ext

一切由grid开始,首先，我需要一个grid

var cm = new Ext.grid.ColumnModel([//列信息
            {
                header : '编号',
                dataIndex : 'id'
            }, {
                header : '名称',
                dataIndex : 'name'
            }, {
                header : '性别',
                dataIndex : 'sex'
            } ]);
var store = new Ext.data.JsonStore({//数据源
            url : "aa",//数据
            fields : [ 'id', 'name', 'sex' ]
            })

var grid = new Ext.grid.GridPanel({
                renderTo : 'grid',
                store : store, // 数据
                cm : cm, // 列信息
            });
            store.load();

简单,效率,cm与store是我创建grid必须拥有的,大多数时候我会选择json来传递后台信息,故我一定会使用jsonStore作为Store,为了快速开发我一定会使用fields中的字段直接使用在cm中，也许大神们辛辛苦苦的将cm与store的映射关系分开,但是。。。好的,我现在要将列信息与fields里的信写一起

Ext.namespace("Ext.MyUtil")
Ext.MyUtil.MappingReader = function(mapping,url) {
                if (typeof (mapping) != "object")
                    return;
                //通过mapping分离出2个数组
                var fieldsArray=[];
                var columnArray=[];
                for(var i=0;i<mapping.length;i++)
                    {
                    //我认为我一定会有dataIndex,不判定存在
                    fieldsArray[i]=mapping[i].dataIndex;
                    if(mapping[i].header)
                        {
                        columnArray.push(mapping[i])
                        }
                    }                
var cm = new Ext.grid.ColumnModel(columnArray);
                var store = new Ext.data.JsonStore({
                    url : url,
                    fields : fieldsArray
                })
                store.load();
                return {
                    cm:cm,
                    store:store
                }
                        
            }

这样我写一个mapping依照cm的格式与fields的数据写一个就行了,当然我默认认为cm里的dataindex的内容是被fields包含的，也许你会觉得没有用,不过我这里是纯ext开发,最老的js代码有3w行。。。展开想象力吧

写一个mapping将grid所需要展示的内容表达出来对我最大的好处就是将注意力集中在事件上,我会尝试着把同一文件夹下所有的mapping都写在一个js中,在我的grid中维护的是各种事件,当然首先要写好mapping,我需要处理下面这些麻烦(现想的哦)

一.编号与复选框

对于我现阶段开发的grid没有编号与复选框的情况是不存在的,我可以直接将sm写进去

二.按钮，事件

这些新增之类的bar肯定是必须的,我可以将所有的bar事件写在一区switch(but.text)来进行统一的维护(目前所有bar的text跟功能一一对应的)，对于常用的事件,或许我也可以提供一些默认的事件

三.grid的宽度

我现在接触工作的全部都是extjs写的,某种意义上grid的宽度一定需要自适应,根据客户的需求写死宽度一定不会有错,不过如果可以的话按比例自适应写起来应该更加的简单

四,其他事件

最开始我想提供一个简单的写sm与cm的方式,然后变为提供一个自己使用的grid,不过如果需要自适应,我可能必须给grid一个父容器,当我创建一个grid的时候我会创建一个容器，比如panel然后再加入grid,这样肯定是不正确的,不过先尝试一下,效率的问题以后再说。。。

只有一个grid多少有点无聊，再让我尝试一下panel

我现在创建的panel就跟二维数组一样,他一定会是一行多列的,一定会每行宽度一样的,也一定是。。。总之他就是你所能想象到的最简单的那种

既然有了这么明确的设计方式,为什么不让panel的创建就像二维数组一样呢(原本想的是form，不过form里面嵌套form多少是不规范的,使用panel仿造form功能就是了)

写一个简单的

    // Ext.namespace("Ext.MyUtil")
Ext.MyUtil.getPanelItemsFromArray = function(array) {
                if (typeof (array) != "object")
                    return;
                var obj = [], objc = {};
                // 通过array获取行信息后分离列信息
                for ( var i = 0; i < array.length; i++) {
objc=Ext.MyUtil.getPanelColumnFromArray(array[i]);
                    obj.push(objc);
                }
                return obj;
            }
            // 构造列信息
Ext.MyUtil.getPanelColumnFromArray = function(array) {
                if (typeof (array) != "object")
                    return;
                var items = [];
                for ( var i = 0; i < array.length; i++) {
                    items.push({
                        layout : 'form',
                        items : [ array[i] ]
                    });
                }
                var obj = {
                    layout : 'column',
                    items : items
                }
                
                return obj;
            }

只要我把正常的创建以array的形式传过去,就可以获取一个可以直接使用的items了,其实我也很讨厌这种写死的不灵活的方式,不是我的风格,但是想到我必须面对这些单一的格式,而且我也可以将这一坨坨的代码丢到其他角落的时候，我还是挺乐意使用它的

既然写好了简单的模型,我需要开始挖掘他更多的相同点，我应该讲常用的属性都提出来

一.宽度

fieldLabel的宽度给他一个100,而另一个宽度就直接视为anchor :"100%"，至于每一列的宽度,不管怎么想,原有的columnWidth真是神器啊- -

二.可编辑

我这没有可编辑一说,只有readonly。。换句话说每个小组件上都会有一个readonly,八成以上的情况是添加编辑的时候全部显示,查看时全不可以显示,既然这样,我更换一下有一个getReadOnlyPanelItems就可以少些一个属性了(我很想问需求们,新增/修改/查询这些废物功能能和在一起吗？他们的回答是不可以,这是我们的卖点- -god,大量的渣卖点)

三.验证

我没办法舍弃这个东西,尤其是有那种验证不通过你还要全部保存,仅仅是为了显示那个小红点的破烂需求的情况下

四.事件

我必须有一个load事件,最好还附带save事件,不介意的话我还有几个固定的but要加上,没有问题,不过我讨厌每个model都要有一个action的潜规则(没要求,但是每个人都这么写)我认为少许的action+service+复杂的dao能够更快速的开发这种千篇一律的"软件",那么事件上,我会用一个简单的action处理