IE中的可调整性能

Question

我在使用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()中的所有元素.

Answer 1

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();
}

现在让我们考虑一下.无论如何,这可以说是正确的方法,因为几乎所有的可编辑元素都不会在页面重新加载之前进行编辑(至少在我的情况下是这样).将所有这些元素设置为可编辑以防万一它们被点击是相对于仅在单击它们时使它们可编辑而言效率相当低.