[讨论] 列表组件在实际开发中的应用

最近比较关注YUI-EXT的GIRD组件，一直想学习一下他的代码，并且借鉴一下他好的设计，用到ecside中。

可是由于太过庞大的JS（对于我来说），看起来实在是挠头，于是也就作罢了（但新版本ecside借鉴了他的风格）。

现在市面上有很多基于js和ajax的列表组件，他们不同于传统的jsp tag方式的列表组件。

基于ajax的组件的特点通常是：
页面中使用一些标准的html、js代码
服务器端发送json或xml代码到客户端
客户端利用一套强大的js来解析数据，并生成列表。
（通常导出能力有限，甚至不支持导出）


传统列表组件特点通常是：
页面中使用一些标准的html、js代码，以及jsp tag
服务器端发送的代码已经是最后要展现出来的列表的html(xhtml)。
客户端再利用有限的js来实现一些功能的补充。

两者没有明显的优劣之分，各有所长。



（ecside总的来说站在传统tag列表组件一边，但我一直在努力的提高展现层的体验以及重【发音：众】用js,
但不知道我这样的努力会有什么结果，是把两者的优点结合起来了，还是缺点叠加了呢，这个还有待于进一步的观察和考研）



我在这里想和大家探讨一下下面的问题：
1 在实际的企业应用中，究竟两者中那种方式应用的更广呢？
2 在实际的企业应用中，绚丽的效果和特性，需要的多吗？
3 在实际的企业应用中，通常单页数据显示量超过500条的页面会很多吗？
4 在实际的企业应用中，通常需要的最大单页显示数据数目会是多少？
（我们这边是单页5000条）
5 列表组件不等于报表组件，但是在实际的企业应用中，拥有一定的统计汇总特性的列表组件肯定是受欢迎的（没有哪个企业会为了一些简单的统计功能就去使用复杂的报表组件的），那么大家通常最希望列表组件具备报表的哪些基本功能呢？

6 以后补充。。。。。

Grid超出普通HTML table的意义在于几个方面：
1.现场编辑。直接在cell编辑数据。同时保留良好的浏览效果。
2.多条纪录的客户端数据缓存。编辑多条纪录，然后批量提交，交互的效率更高。

主要是这些。一些利于浏览的客户端排序、调整列的排列顺序、锁定行头列头等特性则相对次要。

不管用什么方式，单页数据在浏览器中都不宜过大，一般我认为500足够多了，结合查询和分页的技术。

最好不要把统计汇总等功能搞进来。或者要分清楚。简单的单据明细总数的算法是可以的，更复杂的报表是不宜在客户端用Javascript来执行的，效率是一个大问题。

个人感觉服务器端应该返回纯净的数据，客户端的功能是可配置的，客户端的灵活性,扩展性很强。
理由说不上，觉得这样好。

1最好还是基于ajax的组件比较好，尽量少的用jsp tag实现会比较受欢迎
2分页应该是能够让用户指定每页多少条比较好
3效果的话不追求太绚丽的效果，只需要实用的效果就ok了

但是数据库端返回数据
客户端利用js来组装表格 这样的做法速度实在是一个大问题啊

采用Ａｊａｘ的方式来显示数据在速度上我觉得会有很大的提升（在服务器端组织输出），在我实际生产的时候发现单页显示超过200行，无论采用何种方式（在服务器端组织输出要好很多），都有速度慢的情况，通常我们跟用户的约定是每页在25－50行之间，同时也提供单页显示调整功能，不过不允许超过三位数。

根据我的经验，一般的情况我在实际项目中慎用Ajax，公司也不推荐，特别对于一下报表之类的东西更是这样。

对于报表最好是采用比较成熟的报表工具，这样在格式和速度上能给客户更好的体验，同时也可以为下期项目赢取时间。