views:

119

answers:

2

I am seeing very poor page set-up time in IE using 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();
      }
     });
});

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.

Any thoughts or suggestions?

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

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

A: 

I am developing similar functionality for a page at the moment and your post gave me a hell of a fright as I've haven't looked at it in IE for a few days.

However I've just looked at it now in IE 6 - 8 and I don't experience the same poor set-up performance that you do. I have 13 rows, each with 6 editable fields. Page load and performance after load are both snappy. I created a similar page with multiple editable elements which has been live now for six months with no reports of slow performance. Looking at it now in IE it has 130 editable elements and it's just as snappy to load and perform as my current page.

In both cases I have attached jeditable in a much more sloppy method than you have using a single class as the selector.

So I'm not convinced that your issue is jeditable.

Maybe it is though. When I've got the behaviour I want with my current page I'm going to try binding jeditable to a higher level container and use event bubbling as discussed in point 7 of this post 11 ways to increase your jquery performance. Maybe this will help you.

Best of luck.

Che
A: 

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.

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.

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.

fsb