尝试在项目中使用Gt-Grid后的一些体会和看法及建议。

一直现找个称手的Grid，在关注Ext Grid的时候顺便了解到了fins开发的Gt-grid,上星期偿试把它加入到我现在的一个项目和框架里，遇到了不少问题，我把它写出来，希望fins能看到。
      首先，我认为Gt-grid(下面我简称它为GT)只是一个Grid，它只是一个展现数据的工具(fins不知道是不是跟我一样的想法，或者，他的目标是一个框架也有可能)，而并不是一个框架，因此，我希望它对我原先系统或者框架的应用是无侵入的，也就是不应该改变我原先的项目及框架(服务端或者客户端)的操作使用习惯，要做到这一点，GT就要具有高度的可配制性来适合其它的框架或者组件（或者叫应用吧,当然，如果是一些新开工的小项目，也可以让项目来适应GT）。
    Grid一般都有如下功能:
         1    表格数据的展现;(基本的)
         2    数据展现和编辑时的一些事件处理(我认为这些是开发企业应用的重要功能);
         3    从服务端加载数据;(非必需的)
           4    分页导航(重要的);
         5    一些自定义的配制及样式(非必需的)
         6    其它的扩展功能(非必需的)
先谈谈第一个遇到的第一个问题:
      如果是从服务端load数据，pageinfo要求的格式是这样的{ pageSize : 20, pageNum : 0, totalRowNum :0,totalPageNum : 0, startRowNum :0, endRowNum :20 }，很不巧，我用的服务端框架返回的数据格式(pageinfo)名称除了pageSize,data，其它的都不相同，当然，我的服务端名称是可配制的，返回这样格式的数据不存在问题，不过它会影响或者导致同一项目里的二种数据格式，如果GT能提供这些名称配制的方法（应该也是很容易的），这个问题就解决了。下一个问题是我遇到的第二个问题，我使用GT的主要目的是想用它来展现数据以及用到它的事件处理，这方面对比下来GT做得还是让我很满意的，也是我选择它的一个主要原因，另外一个原因就是GT的开发者是国人，沟通更方便。基于我的使用目的，我的问题也由此而来(需求真的是千奇百怪...),我希望我把数据给GT（Json,非服务端加载），它给我展现数据，这没什么问题，可是问题由此而来，GT自动根据我给出的数据记录数生成了分页，可那不是我想要的，我想要服务端load数据的那种分页，GT没提供给我，也就是说GT的分页不提供设置功能,要么你前台给我数据，我给你自动生成导航，要么我load服务端的，也给你自动生成，试用下来后好象没有其它方法了，查了API,只有getPageInfo，如果有setPageInfo,getPageNav(得到导航条内容)，addPageNavTo(把导航导添加到某个容器里，比如div里),分页按钮的click事件支持.查看了API，GT没有NAV这方面的属性，也许是没有公开吧。第三个问题，日期控件的问题，以前没看到有日历控件，奥运会一开完，多了个难看的日历控件，提供自定义的使用日期控件的方法，是我所立刻想到的，否则，一个程序里有二个甚至更多的不同风格的日期控件也不是不可能。
最后是Select控件，可能弄起来比较难吧，如果能提供第三方的Select控件的支持，是不是更好。
            下面想到的是添加扩展ToolBar,添加自定义按钮的功能(这些是扩展功能了)......,暂时想到这些了，以后想到了再继续来写。也许，有人看了后会说，你干脆让fins定制得了..........
      

       

我也看了Gt-Grid的demo。效果做的不错。不过我没有在项目中使用。而是使用了e3.table 。
一个好的Grid是项目中基本都要用到的！大部分时间只需要以下基本功能：
1、表格数据的展现。
2、 分页导航。

我们的开发语言是java.所以希望前台列表是标签。后台传递list或result数据类型来填充、传递总计录数、实现ajax。这样就可以降低开发难度，提高开发速度。

Gt-Grid效果做的很好。但是很多功能对我看来不怎么实用。功能太多反而增大了整个js包。而且比较担心的一个是fins一直没有开源或明确不收费。只是比较含糊的说长期免费不开源。担心又会演变正一个新的ext.而且国外有个收费的grid。fins承认是他写的。但是不愿别人知道此事。所以对Gt-Grid的未来不明朗。所以放弃了Gt-Grid。

我很希望java能出象.net那样的grid.提高开发速度。建议Gt-Grid出两个版本。
1、基本版本。具有展现、分页、ajax、标签功能。
2、高级版本。

基本版本开源免费、高级版本收服务费。这样既保证个人的利益。又让大家了解Gt-Grid。不担心Gt-Grid的将来。可以在实际项目中大量使用Gt-Grid。

希望fins能认真考虑此事！

to xiaocon
非常感谢你的关注

首先我要说明一下GT-Grid的定位
GT-Grid如他的名字所说 将只专注于列表组件的开发,不会企图做成一个大的框架.
同时 它会努力的让自己与其他的优秀框架相兼容.

好 下面我来简单的回答一下你的问题吧 也许我的回答并不能消除你所有的疑虑 不过我想还是能表明一些我的想

法,如果有不妥的地方 欢迎提出来

答 第一个问题 : 
那些变量(属性)的名字都是可以改变的.
通过改变几个常量来实现.只是我没有提及/
因为太多的灵活性 往往会给使用造成一些不必要的困扰,尤其是在我没有充裕的时间来写复杂详尽的文档时.
而且 虽然这只是一个普通的组件 并不是一个框架(以后也不会是)
但是我依然非常信奉ROR里的"约定大于配置"的宗旨. 有些事情提供太多的灵活性未必是好事.

尤其对于一个产品而言, 每一个灵活性 都意味着更多的测试 更多的文档 更多的客户服务 ...

当然 必要的灵活性还是要提供的 不过 这个度 是需要长时间的摸索而来的

例如你说的这个问题 之前还真没有人提起过. 但是今天你提出来了 那么 下一步我就会去考虑.

不过 不是所有需要我去考虑的建议和意见 最终都会被采纳 , 原因我在这里说过一些:
http://fins.iteye.com/blog/218435 (看主贴的后半部分)


答 第二个问题:
你的意思是不是 GT只负责显示数据, 而导航条上的信息由开者自行设置. 而导航按钮对应的函数也由开发人员来

指定? 或者是 可以在外部设置自己的导航条来代替GT的?

这个问题我不知道理解的对不对 希望可以就这个问题和您展开深入的交流
关于导航条的设置 我也很疑惑 如你所说 其实关于导航的函数其实写了很多 我只是没有暴露出来
因为觉得设计的不够好 还在寻求更好的方式

期待和您关于这个问题的进一步讨论.


答 第三 四个问题:

日期组件 和 comboBox 组件确实 让我很为难.
目前的日期组件使用的是第三方的 comboBox不支持 只支持标准的select.


首先 这两个组件我自己是肯定不会去写的. 你所说的"提供自定义的使用日期控件的方法" 这个也是我希望的.
但是一直没有想好怎么做. 因为这对那些组件要求比较严格.
现在你看到的那个日期组件 其实也是我修改了他的代码 才勉强能用的.

提供"自定义编辑器"的功能不难 难的是让这个功能简单易用.
这个问题很难解决 但是确是必须要解决的 不过目前还没有一个明确的想法.
希望2.0版本里可以侧地解决.



最后一个问题 :"添加自定义按钮的功能"
目前是支持的 在1.12版本的示例里就有.
不过目前功能还比较弱,只支持图片按钮 不支持带有文字的按钮
而且也仅仅是支持按钮 不支持任意合法HTML代码. 这些在未来版本中也是一定必须要解决的.

谢谢您的督促.

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

最后 再次感谢您的关注 您的每一个建议 意见 督促 不满 ... 都是我继续前进的力量

我想不出什么更华丽的辞藻来表达我的感激之情了, 最后还是把最简单的文字送给你吧:

谢谢你!

谢谢fins的认真回复，关于第一个的问题，我谈谈我的看法，当然，你也说了，其实是可以通过改变常量来解决的，那说明当初也考虑到了这些问题，只是可能还在考虑要不要暴露出来，我想说的是这些参数跟很多的应用其它框架都有关联，前台的，后台的，都有，而各个框架都有自己的命名方法，所以我觉得这方面的灵活性应该是很有需要的，如果gt想更广泛地其它框架配合应用的话．关于第三，第四个问题，项目里界面风格的统一也是很重要的，否则很可能因为一点点地方的疏忽(国内对项目的好坏首先是建立在好看与否的基础上的)，导致得不到客户的好评，或者对项目评论的减分．
关于第二个问题，我认为应该可以写成类似于一个控件，让用户对控件拥有可控性可能会更合适，比如我的需求是我会用我自己的方法从服务端得到要展示的数据及总记录数，当前页码，按多少条记录一页来分页，更详细的可能会有从第几条记录起取多少条至多少记录止，还返回了是从哪个文件返回数据的，具体参数是什么，在这些都具有的情况下（我希望是用我自己的方法来得到数据，否则从服务端取数据会有二种甚至更多的方法，我想要保持的是模式的统一，以方便后人的维护），希望gt能做的就是根据我给出的这些数据和参数，帮我显示导航条，gt导航条上的按钮本来是执行gt的load方法(去服务端取数据)，现在换成执行我自己的方法，至于取不取得到数据，或者说后面的行为已经与gt无多大关系了，也就是说在我的项目里至少它已经被利用完了，它的使命也结束了(抱谦说得难听了点)，然而这样做的方法也是对我的系统侵入影响最少的，至少其它人很多项目的改造如果以前也是在用的ajax的，现在想换成你的gt显示表格的话，我想我的想法应该有一点代表性．

我在你的ＱＱ群里的，只是难得看到你显身．

to wlghd :

同样感谢你的建议.
将 GT-Grid 进行细分, 功能不同 代码不同 体积不同 收费标准不同.... 这个想法我也一直有
但是 目前GT-Grid的设计 并不适合做这么细分.这个不是因为组件的松耦合做的不好,而是整个架构的问题.
例如 完整代码加一起:

工具代码+ 基础代码+ 父核心模块+ 子核心模块+ 功能1+ 功能2 + 功能3 + 功能4

代码的重头在 "工具代码+ 基础代码+ 父核心模块+ 子核心模块" 这部分
就算你只要功能2 那么代码组成也可能是:

工具代码+ 基础代码+ 父核心模块+ 子核心模块+ 功能2.

代码体积可能只小了 功能3 + 功能4 ,到最后 一看大小,你会发现 只少了几K.


不过 代码之间的可分离 松耦合 是亘古不变的王道 所以 我也会努力的向这个目标前行的.

谢谢你的建议.


e3.table 是很不错的列表组件 但是和GT属于完全不同的类型
两者并不冲突.
gt以后也会做标签版本, 但是我想gt和e3不是竞争关系, 各有各自擅长的领域.
希望两者都可以有好的发展 也希望以后可以有机会和e3 合作 .

那个国外的收费grid我之所以不愿意提起 是因为它虽然是我开发 但是所有者不是我.
它的核心代码和GT一样,但是和GT完全是两个产品.


关于GT的收费问题. 这个你放心.
GT即使有一天真的收费了 也会以一个全新的版本作为起点 对于现有版本没有什么影响.
以后如果要收费 应该是这样:
免费版本停止功能开发 只做bug修改和文档补全.
全力开发收费版本 以及收费版本的文档 和技术支持.
免费版本不会收费.