EXT 2 绚丽表格背后的隐忧

GT-Grid 开发日记( 2007-10-10 ) | GT-Grid以后打算重点支持 IE FF Safari, o ...

2007-10-09

ext2 的demo和alpha一放出,立即吸引了全球ajax爱好者的目光.

我和很多人一样被深深的震撼, 完全拜倒在他面前.

由于我也一直在研究grid组件, 所以对他的grid很感兴趣.

看了DEMO之后, 除了自叹不如之外还是自叹不如 :).

可以说 ext 2的grid是目前基于js实现的列表里最出色的(没有"之一").

但是 EXT2 的表格里有一个很重要的变化.

列表不再是由一个table组成. 而是变成了由n多个div和table组成.
每行数据是一个table.
下面的代码是一条记录对应的 html代码. 注意: 只是一行数据.

<DIV class="x-grid3-row  x-grid3-row-selected " style="WIDTH: 579px" rowIndex="0">
     <TABLE class="x-grid3-row-table" style="WIDTH: 579px" cellSpacing="0" cellPadding="0" border="0">
      <TBODY>
       <TR>
        <TD class="x-grid3-col x-grid3-cell x-grid3-td-company x-grid3-cell-first " style="WIDTH: 269px">
         <DIV class="x-grid3-cell-inner x-grid3-col-company" unselectable="on">
          3m Co
         </DIV>
        </TD>
        <TD class="x-grid3-col x-grid3-cell x-grid3-td-1 " style="WIDTH: 75px">
         <DIV class="x-grid3-cell-inner x-grid3-col-1" unselectable="on">
          $71.72
         </DIV>
        </TD>
        <TD class="x-grid3-col x-grid3-cell x-grid3-td-2 " style="WIDTH: 75px">
         <DIV class="x-grid3-cell-inner x-grid3-col-2" unselectable="on">
          <SPAN style="COLOR: green">0.02</SPAN>
         </DIV>
        </TD>
        <TD class="x-grid3-col x-grid3-cell x-grid3-td-3 " style="WIDTH: 75px">
         <DIV class="x-grid3-cell-inner x-grid3-col-3" unselectable="on">
          <SPAN style="COLOR: green">0.03%</SPAN>
         </DIV>
        </TD>
        <TD class="x-grid3-col x-grid3-cell x-grid3-td-4 x-grid3-cell-last " style="WIDTH: 85px">
         <DIV class="x-grid3-cell-inner x-grid3-col-4" unselectable="on">
          09/01/2007
         </DIV>
        </TD>
       </TR>
      </TBODY>
     </TABLE>
    </DIV>

当然我也知道,把一个大table进行拆分可以避免table的很多先天不足(例如渲染方面的).
但是这样的dom结构未免太复杂了一些, 当页面数据很多时, cpu \内存还有脆弱的IE能否支撑起整个列表呢.

其实ext grid以前在实现一些特性的时候, 使用的方法也就不是很好, 例如那个列表内部滚动条, 例如列表头的图标处理.(不是指代码写的不好,而是dom的结构设计上就有一些问题,完全可以更简单),

这次重新设计的基于row-table的grid结构真的是更好的方案吗?
我对这种设计并不是持否定态度,而仅仅是充满疑惑. 欢迎大家一起来讨论.

19:44
浏览 (5750)
评论 (38)
分类: js & ajax
进入论坛
相关推荐

hotbarsmu 2008-07-06

仅仅解决问题而已，论坛里最重要的就是互相帮助，希望是就事论事，LZ扯远了

fins 2008-07-04

楼上的真是锐道的好员工啊
dorado整体表现确实不错但是没有哪个单项可以用优秀来形容
目前不具备走向世界的能力.

由于某种原因我不便于对锐道的产品进行公开的批评或是公开的表扬

所以就不说什么了

另外楼上的以后别挖老帖行吗???

hotbarsmu 2008-07-04

http://www.bstek.com/dorado5/performance/test-performance2.jsp

这个例子是显示了2000条记录，可以编辑的表格，显示时间大致1-2秒，不知是否满足楼主的使用需要，具体技术问题，你可以咨询这家公司的技术人员

goodfifa07 2008-03-11

请问怎么把editorGrid里的值传到后台Action里

sleets 2008-02-09

fins 的测试使用的什么浏览器呢？
firefox 3 / opera 最新版本都很慢吗？

像css select测试ie就和其他浏览器差距巨大。我想现在那些开发jslib的大大们应该都是尽量面向将来，即将过时的ie6就不需要下那么多工夫了。

不过话说回来，我认为ext2的服务端排序完美的解决了加载慢的问题。一次把全部数据载入对带宽和数据安全性也是一个考验。

cayenne 2008-02-02

肯定要考虑翻页的吧

clasp 2008-01-27

同意楼上观点。我想如上面提到的变态需求可以通过服务器端生成html再显示到页面的方式来渲染呀，使用动态渲染方式(如动态加载js,服务器端动态生成ext的JS，"动态加载js我们已实现，效果还不错")

menjoy 2008-01-27

我觉得使用EXT，你就考虑每页几十条的分页的情况吧，要想让他几千条的显示，就别想了，不适用。但不是说不可以变通，譬如楼上提到的变态需求，如果打印，可以弹出个窗口，用EXT面板在服务端获取自己生成的表格么，这样性能上的问题就解决了
好的东西总是有他的弊端，看你怎么去变通的解决，我还是喜欢EXT，希望大家也都能用的舒服些！

xqstation 2008-01-08

呃.莫非PM的CPU比较好...我的测试结果与楼主不同...
LOOK:

测试步骤：使用循环生成数据，然后用EXT渲染。每项测试条目执行三次。
由于没有专业的测试工具，我只能通过任务管理器来观测内存使用情况。

测试相关信息：
操作系统：WindowsXP.SP2
浏览器：IE7.0
CPU：Intel PentiumM 1.73
内存：1GB
初始内存占用：737M。（已打开浏览器）

测试1：100次循环数据
（1）创建数据用时:0ms; 渲染用时:531ms
（2）创建数据用时:16ms; 渲染用时:515ms
（3）创建数据用时:0ms; 渲染用时:531ms
使用效果：正常
内存占用：756-758M。
CPU：渲染时占用100%。鼠标移入EXT-GridPanel时占用0%-35%。

测试2：1000次循环数据
（1）创建数据用时:16ms; 渲染用时:4281ms
（2）创建数据用时:32ms; 渲染用时:4250ms
（3）创建数据用时:16ms; 渲染用时:4219ms
使用效果：鼠标移动或点击某记录时，显示效果稍有延迟。
内存占用：777-778M
CPU：渲染时占用100%。鼠标移入EXT-GridPanel时占用30%-60%。

测试3：2000次循环数据
（1）创建数据用时:63ms; 渲染用时:9687ms
（2）创建数据用时:62ms; 渲染用时:9610ms
（3）创建数据用时:47ms; 渲染用时:9563ms
使用效果：延迟较严重，并导致使用复制字符等操作无法正常使用。
内存占用：793-800M
CPU：渲染时占用100%。当鼠标移入EXT-GridPanel时占用100%，窗口处于非活动状态时还持续了一段时间

测试4：5000次循环数据
（1）创建数据用时:141ms; 渲染用时:31672ms
（2）创建数据用时:172ms; 渲染用时:31594ms
（3）创建数据用时:140ms; 渲染用时:32907ms
使用效果：浏览器已无法正常使用。
内存占用：860-875M
CPU：持续100%

cqwww 2008-01-01

怎么就没有人说那个ext-all.js超大？0.5M啊。。。一台100共的server能拖多少用户，客户端还超占内存、CPU，加载也超慢。

AJAX干什么的就是减少数据的访问。。但是这个呢？

fins 2007-11-07

他的表格的最大缺点: 不是实时滚动.

而一页显示很多条记录的时候, 有一个很重要的意义:
可以通过滚动条,快速的浏览所有的记录, 对所有记录有一个宏观的印象.

想一想你在看论坛时, 如果论坛目录里一页显示 1000条帖子信息.
但是滚动条不是实时的, 而是像dorado那种在你漫无目的的浏览帖子时,是不是很费劲???

我举个例子,
一个人员列表,有15列 1000条记录.有一列是是"地址"

你想看看哪些人地址那项没填写, 但是不要求精确的, 你就想看看有没有人那项没写.

我再举个例如, 如果列表里男性名字用红字显示, 女性用绿色字显示, 你想大概看一下男的是否比女的明显的多很多

... ...

我这里"对所有记录有一个宏观的印象" 就是指这种目的性不明确, 而是在列表显示出来之后, 临时产生的需求和想法.

那种有目的性的你可以利用搜索利用过滤利用统计来得到.
但是一个快速便捷的方式进行快速浏览还是很重要的.

例如我不认为你看任何书, 都是通过目录来找页数再去看的.
很多时候,我们都会喜欢"随手翻翻", 而dorado的列表显然没有为我们提供良好的"随手翻翻"的方式 (但不是没提供)

我再补充一下:
dorado那种滚动方式实际上已经和分页没有什么太大的区别了.

frank.zhang 2007-11-07

fins 写道

有人这么做过 rico-Livegrid tubroGrid dorado 都这么做过

但是实际效果并不是很理想

dorado的技术比较好玩但是失去了一些同一页显示很多记录的意义.

我也认为dorado的表格做的蛮好。
同一页显示很多记录的意义是什么意思？

咖啡刀 2007-11-07

fins 写道

这样的情况不应该出现
但是实际情况是"常常出现这样的需求"

我也不明白为什么但是就是有这样的需求
楼上的如果做过行业软件就知道了
客户那边想法很简单:
"C/S程序可以 B/S也一定要可以"
"为什么数据多了一定要让我分页呢??"
"我承认,每页3000条数据,我不可能都看,但是一起显示出来,要比分页看起来更方便"

而且有时候他们需要打印排序(页面级排序),统计(页面级)...
总之这样的需求太多了
我遇到的最变态的是要求有多少显示多少,后来跟他们商量变为5000条/页了

我也确实遇到了这样的事情！！！当时我采用的分页！！
但客户就一句话，我需要数据库一次性全部显示出来！！
哎！！无语啊！！！
数据量都超过1万条了！还说要整页显示！！！
遇到这样的用户！！使用Ext这还不被客户给骂死啊！！！
性能更本就不能保证了！！

fins 2007-11-07

有人这么做过 rico-Livegrid tubroGrid dorado 都这么做过

但是实际效果并不是很理想

dorado的技术比较好玩但是失去了一些同一页显示很多记录的意义.

microboat 2007-11-06

这种情况是不是可以用google地图的方式解决？页面上显示10条记录，下面隐藏10条，滚动条滚动的时候后台去填充下面的隐藏数据

allenleex 2007-11-05

变态的需求只能用变态的做法，Ext不是考虑变态的情况的……
我就这样认为，所以用任何技术，必须考虑可以用在哪里，至于其他实在不合适的场合，根本不要勉强使用。

^o^

fins 2007-11-05

传统方式,由服务端直接生成 html table代码
而不是利用js来拼装table .

可以借助 displaytag extremecomponents 或 ecside 这类的组件.
也可以自己 for + <%= ... %>

wangyl_2008 2007-11-04

1000条显示好多客户都有这样的需求，我想知道大家这里都是用什么控件来实现的

fins 2007-11-04

boyjunqiang 2007-11-04

没有什么系统需要一个页面显示1000条数据的把

发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

fins

浏览: 743412 次
性别:
来自: 小胖儿的大城
详细资料

大城小胖的大城