4

jeditableを使用したIEでのページ設定時間が非常に短くなっています。

このページには、次のようにjeditableが適用される13のスパン要素が各行に含まれるテーブルがあります。

$(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では、上記のコードはテーブル行ごとに0.5秒以上かかります。したがって、ページ設定の遅延は、10行のテーブルではすでにひどいものです。ユーザーはそれに満足しません。WebKitとFirefoxでのセットアップの遅延はごくわずかです。

何か考えや提案はありますか？

パフォーマンスのためにjeditableコードのレビューまたはプロファイリングを開始していません。

また、$（document）.ready（）内のすべての要素ではなく、クリックされたときにのみ要素に対して.jeditable（）を呼び出すことを考えています。

4

3 に答える 3

8

Che、私は一連のテストとプロファイリングを行って、コードのどのビットに時間がかかっているかを判断しました。jeditableだけが原因ではありませんでしたが、それは大部分を占めました。なぜそれが私ではなくあなたのために速く働いているのか私は本当に興味があります。

1つの可能性は、iMacのVirtualBoxVMでXP上でIEを実行していることです。これは高速なセットアップではありませんが、クライアントの中には古い、遅い、または過負荷のコンピューターを使用しているものがあり、アプリケーションもそれらに対してうまく機能するようにしたいので、それは良いことです。

とにかく、良いニュースは、私が共有できるシンプルで効果的な解決策を見つけたことです。$（document）.ready（）内のすべての.jeditable（）呼び出しを削除しました。テーブル内の編集可能な各スパン要素に、onclick = "ed（this）"のような属性を指定しました。そして、ed（）がどのように見えるかを想像することができます：

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

それでは、これについて考えてみましょう。とにかく、これは間違いなく正しいアプローチです。ページがリロードされる前に、テーブル内の編集可能な要素のほとんどすべてが編集されないためです（少なくとも、私の場合はそうです）。クリックされた場合に備えてこれらすべての要素を編集可能として設定することは、クリックされた場合にのみ編集可能にすることと比較して、かなり非効率的です。

于 2009-11-18T16:38:40.503 に答える
1

これを解決しました。それなしで生きることができるなら、次の4行のコードをコメントアウトしてください、それは私にとってそれをかなりスピードアップします。

       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つの編集可能なフィールドがあります。ページの読み込みと読み込み後のパフォーマンスはどちらも優れています。複数の編集可能な要素を使用して同様のページを作成しましたが、パフォーマンスの低下の報告はなく、現在6か月間公開されています。IEで今それを見ると、130の編集可能な要素があり、現在のページと同じようにロードして実行するのが簡単です。

どちらの場合も、セレクターとして単一のクラスを使用するよりもはるかにずさんなメソッドでjeditableをアタッチしました。

ですから、あなたの問題が編集可能であるとは確信していません。

多分それはそうです。現在のページで必要な動作が得られたら、jeditableをより高いレベルのコンテナーにバインドし、この投稿のポイント7で説明されているようにイベントバブリングを使用してjqueryのパフォーマンスを向上させます。多分これはあなたを助けるでしょう。

幸運を祈ります。

于 2009-11-18T05:27:45.937 に答える