GT-Grid 1.0 基础教程(九)

忘了 补充一下:

真的非常感谢你的关注 和 建议.

我说那么多 不是为了反驳你

其实你说的 是很有道理的 只是我不愿意采用而已.

当然 以后在实际使用中 如果这种需求很多 我一定会及时调整思路的

再次感谢你

我觉得你还是没有明白， 再来强调一次：我前面讲的多重排序/倒序是建议如何在GT-Grid内部实现的细节，而用户如果要使用这个功能，只需要关注于一个栏位的排序function就可以了。
而你的接口设计引入了record和value的概念，但是record其实对于单个栏位的排序是完全用不到的，我猜测你引入record可能是为了实现多重排序，所以建议你换常见的/大家都早已习惯的sort接口，这样可以避免新的学习成本。

至于你说的用户是否明白JS排序的原理，这个大不必担心，你的用户毕竟是程序员，哪怕再新手的程序员，也会听说过快速排序或者冒泡排序算法。

退一步说，哪怕是一个非程序员，他也有上体育课按高矮排队经历：和他人比较一下高矮，交换位置，而不是报一个xxxCM给老师，让老师再给你指定位置。

产品设计中一个重要的理念是尊重用户习惯，不要增加学习成本，而你这个设计恰恰是违背了这一点。

引入 record 为的是在排序时 可以取到更多信息:

例如 按 总成绩排序.
如果由于某种原因 总成绩 并没有在record中, 而且客户也不希望扩展数据列

那么 总成绩列的

getSortValue : function(v,record){
   return record.数学成绩+ record.英语成绩;
}


"产品设计中一个重要的理念是尊重用户习惯，不要增加学习成本，而你这个设计恰恰是违背了这一点。"

首先 ,我不认为这会增加成本. (getSortValue的学习成本绝对比js.sort的学习成本低,而且你乐观的估计了学习 js排序原理的成本)

其次 我不认为这是不尊重用户习惯.

而且 你说的那种方式 GT是支持的 只是不作为推荐的方式, 不会写入文档.


"尊重用户习惯" 不等于 "不提供新的使用方式给用户"

否则 就不会有ajax 了, ajax 改变的就是传统的开发页面的习惯
在GUI出现之前, 用户的习惯是 命令行.
车辆出现之前,人们的习惯是骑马或步行

... ...


好的产品 除了尊重用户习惯之外, 还有"引导用户改现有习惯"的责任.

这个问题不要再争论了 ,
因为这就好像是问 红色和绿色哪个颜色好看一样?

答案是 都好看,关键看个人喜好.

根据下载的示例代码来看，总成绩列应该是通过一个定义加总列来显示的，按照你目前的设计就会变成：

{name : 'total', type: 'float',
    initValue : function(record){
        return record['english'] + record['math'];
    },
    getSortValue : function(v,record){
        return record['english'] + record['math'];
    }
}

这里出现了2次重复的return record['english'] + record['math']代码，这不符合Don't Repeat Yourself原则，顺便问一下，在这里的v会是什么值？

如果是采用我们惯用的sort function，那么代码就可以写成：

{name : 'total', type: 'float',
    initValue : function(record){
        return record['english'] + record['math'];
    },
    sort : function(v1, v2){
        return v1 - v2;
    }
}

而且由于这里是按照数值排序，所以其实用户不需要写sort的定义：

{name : 'total', type: 'float',
    initValue : function(record){
        return record['english'] + record['math'];
    }
}

现在你觉得那种方法更简单方便呢？

还有一个你前面没有回答的问题，我想再提一下：在目前的排序设计中，如何利用js提供的内置功能(localeCompare)实现汉字拼音排序？

看帖不仔细啊 你 呵呵

我说:


也就是说 我的意思是 如果用户 不希望 使用initValue 的话.

如果他愿意使用initValue来阔真数据列的话 , 那么根本就没必要写 getSortValue
所以不存在重复的问题

那这个getSortValue方法是定义在哪里呢？我看了一下下载的代码和文档，没有找到相关的例子。
使用renderer？那么和renderer里面的代码是不是又重复了呢？



按照你之前提到的这个原则，这里参与到了排序操作，不应该使用扩展显示例，所以你最初举的例子实际上就不可能出现。

用renderer的话确实是重复的

但是 如果用你的设计 呢? (用户不想使用initValue来扩展列)

column :
{
renderer : function(){
    return record[数学]+record[外语];
}
}

dataset的record中根本就没有总成绩这项
也就是说 v1 v2根本就是undefined
    sort : function(v1, v2){  
        ... ...
    }  

我说:


这里面 数值转换 以及 排序值的缓存 也是很重要的因素.

举个例子:
服务端 送过来的 数据 是 "月/日/年" 格式的字符串.显示的时候也是  "月/日/年"

我要对这列进行排序.
实际上这个排序要求对数值进行转换,
要么转换成位数相等的 年/月/日 然后做字符串比较
要么转换成日期格式进行比较
不管怎么转换 这个转换成本是不低的.

一定要缓存,缓存的问题怎么办??让开发人员自己写?

还有我下面的需求 看看你的那个方法怎么实现:

按姓名排序, 姓名相等时, 女性在前,男性在后 ,性别相等时, 年龄小的在前, 年龄大的在后.

按照你之前提到的这个原则，这里参与到了排序操作，用户不应该使用扩展显示例，所以你最初举的例子实际上不可能出现。


你是否有做过用户的实际需求调查？这种功能在微软强大的excel里面也没有实现，这个需求其实就是多重排序，对用户来说便捷的操作是GT-Grid提供多重排序，比如定义用户在按住ctrl时候进行点击就是多重排序：
点击姓名列排序，然后按住ctrl，再点击性别列，然后再点击年龄列，这样就能很自然地达到他的需求，而且用户可以自由地定义进行不同列的组合多重排序，而不需要开发人员预先写死。

在这里开发人员不需要定义任何特别的多重排序方法，他只用定义好单个column就行了。

这2个例子都是脱离实际需求的，我还是看不出来在这里放一个record有它任何的实际用途。


我的建议是不要考虑缓存，因为js Array sort是内置功能，它的效率一定是比写映射功能获取值然后再对值进行排序要来的高，如果你有兴趣的话，不妨单独将这一块缓存＋排序的代码拿出来和Array sort做一个性能测试，我们可以另外开一个话题讨论：看看到底要在什么样的数据量和复杂的数值转换程度下，缓存＋自定义排序会比built in sort性能要好。

你的这个不可能出现的假设是错误的, 是会出现的,我遇到过了, 而且gt目前的设计必然会出现这种需求.
我之前也说过"在gt目前的设计下", 你的那种做法 我不会采用 因为很多需求都无法实现.



1 那个你说的类似多重排序的需求是有 而且使用 getSortValue 很容易实现

2 点击A列 但是实际上排序的值 不仅仅是A列直接对应的值,还有肯能使record中的其他的属性值 或者是通过一系列计算得到的值
这个需求也是有的
而且这个需求 实际上非常强大和必要, 可以衍生出很多排序 编组相关的相对高级的技巧

3 实际开发中 我遇到了太多 不知道如何写那个排序方法的人了.



如果 真的有无法满足的需求 例如你说那个 locale比较的 (其实那个取的不是拼音 而是按区位表排列的, 而且它依赖于客户端的操作系统 所以我一直不喜欢用那个东西)
那么也支持你说的那种方法, 只是在客户有确实需求的时候 我才会告诉客户.

最后 我坚持以下观点



这个话题 stop吧 , 根据我开发 和使用列表的经验:
自定义排序算法/方法 这种情况压根就是不多见的 为了一个不多见的问题 讨论这么多实在有些无意义