如保让表格高度为实际的高度

[limodou]

现在好象高度必须设置一个值，能不能设置为实际的高度，即没有纵向滚动条。

[lidatui]

以前是有这个功能的，在我上一次重构的时候为了减少复杂度给拿掉了。

这个功能在有分页的时候最后一页如果表格数据不多，那表格的高度会变得很小。我想过给它一个最小高度的参数，但是如果给了最小高度其实也就能算出一般数据行满的时候的高度了，也会让这个功能变得用处不大。

还有个问题就是如果表格的外面的标签设置了高度（主要是在dialog里），同时表格也开启了这个功能可能就会有问题。

总结上面的提到的，我觉得这个功能有变坑的倾向，而且通过简单的计算就能避免分页的问题，所以我就把它给砍掉了。

[limodou]

因为我现在就是某些情况下并不需要分页，想一页展示。通过什么可以让我来决定height的计算？（在表格外的标签设置高度，这个可以避免）

[lidatui]

表格的高度=标题的高度+行高*行数+样式占的空间（border，padding，margin）

如果有横向滚动条还要算上滚动条的高度。在windows里滚动条是17像素。

当然，如果行数是固定的话用上面的方法比较好算，要是行数不定我想这也是滚动条存在的意义吧。你说呢？

[limodou]

等有时间我再看看。我想的的确是行数不固定。看你的建议是只能是计算了。不过我到是在我的fork中向mmGrid添加了一些属性和方法 ，其中就有总条数。我想在某些处理时有这个值会比较方便。否则就要每次通过items()得到所有数据，然后再计算总条数，感觉效率有点低。另外，象items的处理，因为我看到_rowHtml要使用它，但是我想大部分情况有可能并不需要这个值，因为每次要计算的话，效率有点低。我觉得不如就让用户在render的代码中自已去调，而不是生成好了传进去。这样当数据多时是不是好点。

[lidatui]

感谢你的建议！

设计render传入结果集列表时是因为考虑到行数据之间的关系，我纠结了好一阵也没把他拿掉，但这个参数确实不怎么用到，所以我刚刚拿掉了renderer的items参数。正如你所说它确实会让频繁更新插入节点的操作变得很慢，问题的关键还是items方法的事。

关于items方法的效率问题我做了一个权衡。现在的数据都是放在tr标签中的，这就意味着增删改改数据行不需要维护items列表。现在renderer方法拿掉items参数后items方法所造成的影响应该不会这么大了。

当然这也带来一个问题。由于renderer方法在执行时表格的行还没有插入完毕，所以在里面使用items方法是获得不到数据列表的。我想这个会在以后改进的。

还有，你说的取得总行数的方法是我考虑不周在上次提交时忽略了items方法的效率问题给拿掉了，我已经加了一个叫rowsLength的方法来获取总行数。

再次感谢你发现的问题，以上我已经将修改后的代码提交到dev分支。

[limodou]

我看到rowsLength的实现了。

        , rowsLength: function(){
            var $body = this.$body;
            var length = $body.find('tr').length;
            if(length === 1 && $body.find('tr.emptyRow').length === 1){
                return 0;
            }
            return length;
        }

不过我感觉每次都要去计算还是有些慢啊。在我的fork中我是在add, remove的操作中进行加1，减1的操作，是不是会好一些。这样取总条数是不需要计算。

[limodou]

另外 _populate 中，我是改为了调用 add 方法，因为我要处理树结点，所以简单的插入元素是不够的，还要处理树相关的样式。不过这样一来，初始化的 add 和之后的 add 就区分不开了。这块我还没弄好。可能会加个标志来区分一下，以决定要不要触发事件。

[lidatui]

第一条里，$body.find('tr')方法实际调用的是document.getElementsByTagName，这个方法浏览器直接是支持的，所以速度非常的快，带来的性能问题我认为在这里可以忽略了。

第二条里，add方法是很慢的，因为它使用了jQuery的append方法，我不建议你在_populate方法中使用它。

[limodou]

我使用add是因为我还有样式的处理，比如在添加子结点时要同时修改父结点，让它出现一个+号什么的，所以原来的_populate方法对我来说还是存在问题。

[limodou]

find()可能是快，不过总是感觉它还是要遍历才能得到。

[lidatui]

我曾测试过，在_populate里使用append方法在IE6里数据一多几乎就是卡住不动的。

能给我说一下你具体想怎么实现吗，遇到的问题是什么，或许我能帮助你解决一下。

[limodou]

因为我要实现的是树型控件，所以我想当后台返回数据时，我会一条条添加。数据中会有象 _parent 这样的值，表示当前记录对应的父结点的id。所以在添加某一条记录时，我还要去查找它对应的父结点，然后添加到父结点的后面，同时修改父结点的图标，让它有一个加号。由于有子结点的存在，所以我添加时并不一定能保证是顺序添加的。因些我写了一个通用的添加结点的方法，要对是否存在父结点进行处理。简单的添加满足不了我的要求。

[lidatui]

我当时设计的_populate方法和add方法是有不同的使用场景的。_populate用于在加载数据列表的时候使用，而add方法用于加载完毕后再添加节点。这主要还是为了性能问题做的妥协。

如果是加载列表，是否可以先便利一遍数据列表，把有子节点的数据标记一下，然后再使用_poplate来加载。然后再修改_rowHtml方法把第一列加入图片和缩进来实现树，这样可以在实际插入节点的时候不用回头找父节点。

如果是加载列表后再加节点我觉得add方法是不是应该要有个标记父节点的参数，现在的add方法应该是不满足的，需要再实现个新的。

[limodou]

你说的可以试试，不过等以后有时间了再优化吧。现在主要是先把功能实现，ie6在我的应用中根本不考虑，所以倒是不太担心。我的代码中的确是区分add和addchild的。

[lidatui]

参数height设置为'auto'显示全部行，即不显示垂直滚动条。