ExtJs 4.0 新结构及Buffered Grid实现分析

ExtJs 4.0出来也有一段时间了，改动真的很大，说是完整重构了一遍都不为过。这几天为了找思路便专心看源码，总算弄清了点眉目。

整体改动（流水帐，不全）
类继承机制变了，多了mixin、calParent等新的东西，更方便扩展；
Store增加了缓存机制及动态切换分页（range）的接口，可以实现预读及本地快速切换；
类继承关系变了，多了一堆AbstractXXX的类，还没弄懂它们拆分出来的意义；
组件(Component)变了，它自身也有componentLayout了，与Container的Layout区分开；
Panel及其它复杂组件更OO了，例如header也是个Container，含icon、title、spacer、tool等组件，以HBox（或VBox）布局；
Grid的View与旧版的DataView整合了，如今是view.View -> view.Table -> grid.View，其它的各种实现都改了，后面再说。
Tree几乎完全重构，如今也是由Panel, View, Store组合。在3.X中Store只用于存储单维数组，4.0中加了一个TreeStore直接存储树结构，然后tree.View自己又创建一个NodeStore作中介，将TreeStore转换成1维，以方便从view.Table继承而来的View使用。
其它的暂时没有时间精力去研究，有兴趣的可以自己翻源码，一起讨论下4.X的设计思路。

Grid新结构分析
此次主要是为了Buffered Grid而来，想看看它与3.X中的BufferView有何区别，找点实现Buffered Tree的思路。以下便是我的分析：

3.X中Grid主要由4大块组成： Panel, ColumnModel, Store, View，它们是必不可少的。
Panel: 负责主要界面布局
ColumnModel: 定义元数据属性与列的映射
Store: 存储元数据
View: 监听Store，即时更新界面html

4.0初步分析
注：4.0中，Grid（grid.Panel）继承自panel.Table，它实现了Grid的绝大多数功能，而Grid自身的代码不过数十行而已。但panel.Table为私有类，所以这里Grid也泛指panel.Table的逻辑。（tree.Panel也继承自panel.Tabel）
ColumnModel弱化拆分了，不再是个独立的对象，而是用于表头及View的配置；
Scrollbar独立出来，作为一个新的组件，也就是说现在Grid的滚动条不再是原生的，而是JS控制联动的；
新增了features配置，它会在各主要逻辑处作注入执行，方便扩展；
（其它的没细看，主要是分析Buffered功能）

这里的重点就是Scrollbar了，Buffered Grid的实现主要就是依赖它。因为它目前是独立、模拟的，因此可以很方便地在JS联动过程中进行缓存处理。以文字描述一次滚动条移动的处理流程：

1. Scrollbar监测到scroll事件
2. 根据滚动条位置、行高、列表高、元数据总条数等信息，计算出当前位置应该显示哪些条元数据（Record）
3. 调用Store的guaranteeRange方法，传入调整后的元数据范围
4. Store自行切换数据，载入指定范围的元数据，并发出datachanged事件
5. View响应datachanged事件，更新视图

这里的guaranteeRange方法被调用后，Store会尝试从预读缓存中快速载入Record，如果没有，则会从服务器请求。
可以看出，它与3.X的BufferView的实现机制完全不同，一个是Store中数据全在，只不过选择性地渲染；一个是Store进行数据切换，还是全部渲染。
以下是个人对它们的看法
BufferView：
实现更优雅，所有Record都在，只在显示层动手脚，不影响数据层。所以，这种方式仍能使用全选。
4.0 Buffered Grid：
因为Scrollbar是JS联动，可控性更强，滚动非常平滑，不会出现BufferView那样滚动过快会看到短暂的渲染空白。但它实质上是以修改Store中的数据实现的，所以全选不可用（Store中只含部分Record）。

结束
个人感觉4.0的Buffered Grid实现机制并不能让人满意，但整个4.0逻辑结构非常好（赞一个，可惜代码也多了一倍，也更难懂了），所以它的可扩展性比3.0强不少，潜力非凡。据初步分析，BufferView可能可以通过改造view.AbstractView来移植到4.0上，并且这样一来，Tree也能Buffer了  当然，可能只是幻想而已……
并且因为改动过大，所以已经用了3.X的XD们只能YY下了 

+U.
最近也在读data和grid这2个包的源码

那项目从3平滑迁移到4基本就是不可能了啊

可以这样认为，几乎算是全部重写了

用到Ext的项目或多或少都对它做过扩展，或依赖内部结构写了实现
4.0中可能一些大的配置（例如items, layout）还是保留原样，但其它大大小小的改动数不胜数

例如现在store没有recordType了，因为不再使用Record，而是Model

3.0 刚学了一部分开始用了。然后4.0出来了。头疼。3.X和之前的2.X的其实改动还不是很大。可是4.0就有些在结构上的变化。还在比较两者去区别。。目前还是坚持用3.0 。4.0还没有用。。

开始4.0吧, 3.x就算了...
4.0是飞跃

4.0JS体积比原来大了将近一倍，客户端加载更慢了，大家怎么看这个问题？

压缩之后还不如一张图片，以目前的带宽条件来说真没什么

再之，Ext是用于RIA开发的，代码多并不意味着性能低，它只影响一下首次加载时间（并且影响也很小，至于iframe就算了）
RIA网页慢更多的是界面太复杂，导致浏览器渲染布局慢
以一个10000行的列表为例吧，纯html显示也快不到哪里去
如果是用JS动态生成的，那性能一般会更慢，当然是指一次性生成的那种
而在Ext中，可以使用BufferView之类的缓存技术，只生成可视区域的html，再根据滚动条变化即时渲染，这性能提升就很大了。

强烈建议要支持Bufferview
treegrid的性能完全不行.

为什么不能参造GXT来实现呢.GXT2.0早就实现了bufferview的treegrid了.

这个去官网提比较好，我也提了建议，不过目前没有任何回应

之前研究Ext4.0是为了预研，看看在3.X的项目中能否引入4.0的组件（官方有提供sandbox的示例）
目前个人结论是可行性不高，所以还是转回3.X，尝试借鉴4.0的组件实现开发3.X风格的扩展。

附：
在我们3.X的已有项目中引入4.0可行性不高的原因如下
1. 对3.X做的扩展非常多，引入4.0无法做到平滑嵌入（只扩展了3.X，4.0还是原生的）
2. 两个Ext，就有两套Element机制，会有很多问题（例如对于Ext4创建的组件，使用外部的3.X进行事件释放应该会有问题，因为Ext在注册Dom事件时会记下句柄，以便后面释放。但现在Ext4记下了，Ext3中没有记录）

想象一下，在Ext的Panel中放入YUI的组件   玩笑而已，但尽管它们接口几乎没什么改变，但仍是两套东西。