GT-Grid 的生存之道( 未来规划 )

以前我曾简单(很简单的)的总结过目前列表组件的状况:

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

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

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

[/quote]

就现阶段的情况来看, 传统的jsp tag列表组件的地位正在一步步被蚕食.
传统列表组件的主要优点就是快速, 主要缺点是 客户体验不佳.

但是随着客户端的速度越来越快, 而且单页显示大数据量的场景不多,导致传统列表组件的优点变得并不那么明显,
而随着客户需求的日趋复杂化,传统列表组件的缺点却变得越发明显了.

在这样的大前提下, GTGrid 自然也会选择在客户体验上下功夫.
但是,如果只是重视这一点,那么在web Grid的王者 EXT-Grid面前, GTGrid并没有多少生存的空间.

=======================================================

GTGrid想有好的发展,一定要有自己的独到之处.
目前我能想到的"独到之处"如下,这些也是未来GTGrid的生存之道


1 在功能不缺失的情况下,让组件的体积更小 性能更高,同时兼容传统模式(支持json数据 支持xml数据, 也支持已经生成的table html代码)


2 在功能上继续挖掘,提供新颖的特性.
总是有一些实用的功能等待我们去挖掘 去实现,功能的数量没有上限.

3 结合国情,提供一套独特的"中国式列表".
类似的说法在报表组件里常听到,很多国内公司在宣传他们的报表时都会标榜自己能够实现"中国式报表".
以前我对这个事情一直不以为然,但是后来发现,老外的很多习惯确实和我们不太一样 呵呵.


4 与J2EE后台结合(但依然可脱离j2ee作为纯前端组件使用)
为服务端分页,数据导出,数据统计,数据CRUD,图表展示提供支持.


5 瞄准企业级开发
"企业级开发"有两层意思,一层是指开发出来的产品性能和质量足以支撑起企业级应用,
另一层意思是指支持"快速开发,傻瓜式开发". (可通过提供jsptag 代码生成器 模板等方式实现)


6 结合实际企业应用场景,提供更多列表组件的"周边模块",争取开创一个"以列表为中心"的企业应用模式.
以前我曾说过:
[quote]
很多企业应用系统.不管业务多复杂, 不管系统多庞大, 有70%的模块都是以列表作为入口的.

印象中,我参与过的上一个项目, 至少有300个类似这样的页面: "上下分帧,上帧是查询条件,下帧是列表,双击列表的条目进入一个表单页面".

所以列表这个真的很重要,而且现在用户对列表的要求已经不仅仅是"展现数据的表格"那么简单了, 列表与报表的界限正在变得模糊.
[/quote]

其实,我们的列表组件如果能够再多做一些事情,那么一个企业应用中,很多很多的工作都可以在列表内完成.

所以结合实际企业应用场景,完善列表的功能,是一件很有意义的事情.


=======================================================

目前的GTGrid离目标还有很大的一段距离,但是这段距离时可预期的,因为这里面没有不能攻破的技术难题,
GTGrid现在需要的只是时间 、支持、和我的毅力。
当然时间也不需要太久,我可不希望GTGrid在html+css+js已经被ria打败的时候才推出 呵呵.


我曾考察过很多列表组件,抛开代码质量 架构设计这些后台的虚无缥缈的(对于最终用户来说确实虚无缥缈),
单纯就列表的功能性 灵活性 扩展性 美观程度 使用体验而言,我没见过比EXT更好的.
也许有一些组件的某一个功能点比ext好,但是综合来看,extgrid绝对是当之无愧的 web grid王者.(RIA系的不在讨论范围内).

GTGrid并没有全面超过ext的野心,毕竟应用场景不同,关注的事物不同,
我只是希望在诸多列表组件中,GTGrid能够有属于自己的一片天,哪怕很小很小 :)