IE中的可调整性能 [英] jeditable performance in IE

问题描述

我在IE中看到使用jeditable的页面设置时间很差。

I am seeing very poor page set-up time in IE using jeditable.

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

The page has a table in which each row has 13 span elements to which jeditable is applied as follows:

$(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中的设置延迟可以忽略不计。

Functionality is great -- everything works. But in IE 6...8 the above code takes over half a second per table row. So page set-up delay is terrible already for a 10-row table. User's won't be happy with that. Set-up delay in WebKit and Firefox is negligible.

有任何想法或建议吗？

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

I haven't started reviewing or profiling jeditable code for performance.

我想也许只在点击元素而不是在所有元素上调用元素时才调用.jeditable（） $（document）.ready（）。

And I'm thinking to maybe call .jeditable() on an element only when it is clicked rather than on all elements in $(document).ready().

推荐答案

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

Che, I did a bunch of tests and profiling to determine which bit of code was taking the time. jeditable was not the only culprit but it took the lion's share. I'm really curious why it's working fast for you and not me.

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

One possibility is that I run IE on XP in a VirtualBox VM on my iMac. It's not a fast set-up but that's good because some of my clients use old, slow or overloaded computers and I want the application to work well for them too.

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

Anyway, the good news is that I found a simple and effective solution which I can share. I got rid of all the .jeditable() calls in $(document).ready(). I gave each editable span element in the table an attribute something like this: onclick="ed(this)". And you can imagine what ed() looks like:

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

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

Now let's think about this. This is arguably the right approach anyway because nearly all of the editable elements in the table will not be edited before the page reloads (at least, that's true in my case). Setting up all those elements as editable just in case they might be clicked is rather inefficient relative to making them editable only if they are clicked.

这篇关于IE中的可调整性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！