4

我在使用 jeditable 的 IE 中看到非常糟糕的页面设置时间。

该页面有一个表格，其中每行有 13 个 span 元素，jeditable 应用如下：

$(document).ready(function() { 
    $('#entry_pl span.ples').editable('my_xhr.php', {
            placeholder: '<span class="placeholder">unset</span>',
            indicator: '<img src="indicator.gif" class="indi">',
            data: function(value, settings) {
                return  $('<span />').html(value).text();
            }
        });
});

功能很棒——一切正常。但在 IE 6...8 中，上面的代码每行占用半秒以上的时间。所以对于一个 10 行的表来说，页面设置延迟已经很糟糕了。用户不会对此感到满意。WebKit 和 Firefox 中的设置延迟可以忽略不计。

有什么想法或建议吗？

我还没有开始审查或分析可编辑代码的性能。

而且我正在考虑可能仅在单击元素时才在元素上调用 .jeditable()，而不是在 $(document).ready() 中的所有元素上调用。

4

3 回答 3

8

Che，我做了一堆测试和分析，以确定哪一段代码花费了时间。jeditable 不是唯一的罪魁祸首，但它占据了最大的份额。我真的很好奇为什么它对你而不是我工作得很快。

一种可能性是我在 iMac 上的 VirtualBox VM 中的 XP 上运行 IE。这不是一个快速的设置，但这很好，因为我的一些客户使用旧的、缓慢的或过载的计算机，我希望应用程序也能很好地为他们工作。

无论如何，好消息是我找到了一个可以分享的简单有效的解决方案。我摆脱了 $(document).ready() 中的所有 .jeditable() 调用。我为表格中的每个可编辑 span 元素赋予了一个类似这样的属性：onclick="ed(this)"。你可以想象 ed() 的样子：

function ed(elem) {
    $elem = $(elem);
    ...
    $elem
        .removeAttr('onclick')
        .editable('action_script.php', {
            ...
            }
        })
        .click();
}

现在让我们考虑一下。无论如何，这可以说是正确的方法，因为表格中几乎所有的可编辑元素在页面重新加载之前都不会被编辑（至少，在我的情况下是这样）。将所有这些元素设置为可编辑以防万一它们被单击相对于仅在它们被单击时才可编辑的效率相当低。

于 2009-11-18T16:38:40.503 回答
1

刚刚解决了这个。如果您可以没有它，请注释掉以下四行代码，这对我来说会大大加快速度。

       var savedwidth  = $(self).width();
       var savedheight = $(self).height();
       ...
       settings.width  = savedwidth;
       settings.height = savedheight;
于 2018-09-26T19:06:54.433 回答
0

我目前正在为一个页面开发类似的功能，你的帖子让我大吃一惊，因为我已经好几天没有在 IE 中查看它了。

但是，我现在刚刚在 IE 6 - 8 中查看过它，并且我没有遇到与您一样糟糕的设置性能。我有 13 行，每行有 6 个可编辑字段。页面加载和加载后的性能都非常快。我创建了一个包含多个可编辑元素的类似页面，该页面已经运行了六个月，没有关于性能缓慢的报告。现在在 IE 中查看它有 130 个可编辑元素，它的加载和执行速度与我当前的页面一样快。

在这两种情况下，我都以一种比使用单个类作为选择器更草率的方法附加了 jeditable。

所以我不相信你的问题是可编辑的。

也许它是。当我在当前页面中获得我想要的行为时，我将尝试将 jeditable 绑定到更高级别的容器并使用事件冒泡，如本文第11 条提高 jquery 性能的方法的第 7 点中所述。也许这会对你有所帮助。

祝你好运。

于 2009-11-18T05:27:45.937 回答