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