Ext 4 概述(六)之Grid

　　这次升级Ext 4全部重写了Grid组件。显然，诸多理由和原因迫使我们升级Grid，但Ext 4 Grid向后兼容方面真的很难顾全。为此，我们将会提供一份关于Grid在Ext3升级到Ext4的指南。 [b]智能化渲染 [/b]
　　旧Ext JS 3 Grid工作起来还是蛮不错的。但透过"最小公分母（least common denominator）"的方法论来确定其各种功能的话，很容易带来一点不足的就是，伴随着Grid的每一项功能，都会生成大量的HTML Markup产生。我们不得不面对这个问题。于是在ExtJS 4中，规定Grid的每一项功能，只会根据开发人员设定与否，才会渲染出与之对应功能的Markup在页面上。Grid默认启动时只有为数不多的Markup而已。这样设计API的结果，便是在渲染页面以及Grid整体效能这双方面均得到极大的提升。 [b]标准化布局 [/b]
　　渲染流水线得到了改善，Grid的其他方面亦齐头迈进，不甘人后。许多Grid的部分都被规划成为单独、清晰的Component组件，整合到标准的布局管理系统中，并非旧版中直接处理内部Markup、CSS的那种方式。这使得API可以联合框架的其他强大的特性，进而来统一Grid的渲染流程。而这些过程，仍维持在精确到象素级别水准（pixel-perfect）的UI体验。
　　例如，新的HeaderContainer类就很能说明这个问题。Ext3中的列头部（Column headers）整合到Grid的话感觉是比较生硬的，因此不太容易客制化。Ext4的列头部作出改进，其所使用的HBox标准布局就能够让你在每一列上输入灵活的flex值。 [b]扩展新功能 [/b]
　　在Ext JS 3里面为Grid加入新功能，一般API接口方面有良好的考虑。但现在来看，却没有一种清晰的流程方法去指导，显得比较乱。有时通过写插件（Plugins），有时就写子类。总之扩展Grid的话可能会比较复杂。要解决上述问题，实质就是提供一种彻底灵活的选项操作。ExtJS 4将引入全新的一个Grid基类，称作Ext.grid.Feature。通过继承这个Feature类，对任何Grid其所在模板（Template）进行修改，就可以控制当前Grid视图生成的Markup结果。Features类跟旧版的GridView相似，但能力更强，也更为有用。之所以有用和强大，是在于其对延续Grid功能这点上表现得更为简单和适配。Grid里头的一些功能如RowWrap、RowBody和Grouping都是Fetures之子类。
　　Ext 4 grid相关功能的演示例子有如下： RowWrap RowBody
　　Grouping
　　Chunking/Buffering
　　[b]虚拟滚动 [/b]
　　Ext 4 Grid已经可以做到原生支持"按需加载（load-on-demand）"的数据视图了。虽然这是个虚拟视图，但是的确可以能够做到数据的缓冲。无论上百条抑或达上千笔的数据，都可以保证在Grid轻松显示。无疑，这将大大扩充了Grid数据处理能力。 [b]编辑单元格控件 [/b]
　　我们依然拿旧版对比一下。Ext 3里面要编辑Grid单元格，就必须制定EditorGrid类。通过继承方式可能不太灵活，于是Ext 4就否决了继承的方式，而是采用"插件化"的方式。通过Ext JS4的Editing插件可以自由绑定到任意的Grid的实例，对于全体任何类型的Grid均可使用。于是乎，此举又为提高"灵活性（flexibility）"添泼了一抹浓彩。此外，对于Ext 3中很受大家所欢迎的一款扩展：RowEditor，在这次发布我们也将RowEditor正式加入的Ext 4包中去，成为标准类库的一员。 [b]DataView [/b]
　　GridView的父类更改为DataView。这样做的好处不仅减少了代码量，而且使得Grid更容易制定。因为可以直接发挥DataView的选区模型，应用到任意一种的视图，包括那些非连续的选区，例如通过键盘Home、End、PageDown和PageUp所产生的选区。