huge memory requirement for view with editable fields.

At a guess, the editable field you have pulls in a load of javascript for each field....
As a work-around - have you tried marking the fields as 'click to edit'?

Cheers

Mark.

Ahh, yes, you should probably update to the -dev version - but, not, you need dev versions of cck etc :-(

the -99 - 99 shouldn't have much effect.

Cheers

Mark.

Maybe you need to update,php or clear your caches?

But, you should get two options for a field now - 'Editable' and 'Click to Edit'. These should be available for view fields, or content fields display settings....

Cheers

Mark.

Click to Edit seems to just about work on a View of 400+ nodes (using the latest DEV versions of CCK, Views and editablefields). I reduced the View down to <100 nodes and the Editable nodes works (just - although you have to wait a bit for the editable boxes to be generated). But this is only on my Dev machine, which has 6GB of RAM - I'm also using Safari 4 to create my site content, as it seems a lot faster/stable than Firefox on the JS front (no - please don't start a flame war over browser speeds). I think I'll probably limit the use of Editable fields on the production site for the moment, but think it's a fantastic UX improvement.

I'm having the same issue, and unfortunately click-to-edit won't work for my use case based on how we need the UI to look. My use case is almost exactly the same - a CCK content type with 7 fields - one imagecache image, four content taxonomy fields (three drop-down, one freetag), and two text. My view currently is set to display a total of 5 nodes on a single page. When I load the view, it hangs the browser, consumes huge amounts of memory, and just about kills the system. In my case, at the moment I have all Drupal performance options disabled. I am on D6.13 with the latest 6.x release version of the module since that had a later date than the development release. I am using CCK 6.x-2.5.

I did try this with the Firebug console open and saw tons of interesting things - the console log grows until it hit 844 messages and then told me it could not take any more messages. It seems to first loop through the nodes and loads all of the javascrpt, but it does this multiple times. I see it loading all of the javascript for each node so the same script has a GET request issued 5 times on load. The same is then true for each field - it loops through each of them and loads up /editablefields_html/NUMBER/field_myfieldname/0 for each field in each node. This seems to continue to loop forever which is why firebug runs out of message space. I managed to get the Firebug net console up at the same time, and I see hundreds of "GET 0" requests. If I open up the request, they are XMLHttpRequest type and what comes back in "content" looks to be the contents of the fields. For example, my field "color" has about 20 different names of colors, and I see them in the response. If I look in the same response in "scripts" I see all of the various .js files.

The end conclusion I have is this seems to be looping somehow, and even when the content on the page stops loading and appears 'finished' to the end user, the GET 0 and XMLHttpRequest stuff keeps going in the background until the browser dies. I have no idea why, but I'd really like to figure it out if anyone has a suggestion.

I have screenshots of all of the above, but I would prefer not to post them publicly. Let me know if you are interested and I'll e-mail them.

I managed to solve this problem using click-to-edit and custom implementation of Event Delegation that overrides Drupal.behaviors.editablefields.
We have a view with 10 editable field columns and 100 rows. This would mean that in the normal implementation we would have 1000 event listeners. Even with the Click-to-Edit version it would take more than 10 seconds to render the page.

Using event delegation (see below) the page renders almost instantly (ie. there is no noticeable difference than having JS disabled).

Basically for my view where I have the editablefields problem I do a hook_preprocess_views_view_table and then include the custom JS file below that overrides the default behavior of Editable fields.

/**
 * Override the default Drupal.behaviors.editablefields implementation.
 * This currently works only for Click-to-Edit version of Editablefields.
 * If you have jQuery >= 1.3, $.live() might be better suited for this job but the concept is the same.
 * Further reading about event delegation:
 *   http://developer.yahoo.com/yui/examples/event/event-delegation.html
 *   http://icant.co.uk/sandbox/eventdelegation/
 **/
Drupal.behaviors.editablefields = function(context) {
  $('body').not('.delegated-processed').addClass('delegated-processed').click(function(event){
    if($(event.target).not('input, textarea, select').length) {
      if($(event.target).is('div.clicktoedit')) {
        // direct click on the div.clicktoedit
        Drupal.editablefields.init.call($(event.target));
      }
      else if($(event.target).not('input') && $(event.target).parents('div.clicktoedit').length) {
        // clicked on a span (or any other element) inside the div.clicktoedit
        Drupal.editablefields.init.call($(event.target).parents('div.clicktoedit'));
      }
      else if($(event.target).is('td.views-field') && $(event.target).find('div.clicktoedit').length) {
        // clicked in a td of a div.clicktoedit
        Drupal.editablefields.init.call($(event.target).find('div.clicktoedit'));
      }
    }
  });
}

Of course this is very specific in it's current implementation but it does show how a way of solving the problem. Using event delegation means that you can have as many elements in the page without a big impact in performance.
Also if we make jquery_update module a requirement we can use $.live() (that was added in jQuery 1.3) and bind to form elements which means that we might be able to also handle the Html-Edit version too.

Cheers,
Andrei

#9 - would you consider rolling a patch against the editablefields module itself? Perhaps your approach could be adapted for inclusion in the module.

@rjbrown99: I would but to be honest, looking at the current issue queue for this module, I'm afraid that the work would be in vain. Even though there are plenty of maintainers, there seems to be a lack of activity from the owners of this module.

Also, I would like to hear their opinion about this, because without their agreement the patch wouldn't go in.

I will mark this as needs review so that people would test the code from #9 and report back.

Thanks,
Andrei

Your right - I am remiss - I was soo hoping others would pick up on this module, as I'm running short on time.

Andrei, your idea seems a fine one, if the implementation can be cleaned up a little..... I would be more than happy to roll it on - or - better - add you to the developers list.... let me know what works best for you.

Cheers

Mark.

Hi Mark,

I would be happy to put some time into this module as a co-maintainer. I personally really like the module and we are using it within the company (hence the time that I had into researching the issue).

Do you want me to create a ticket where I request to be added as a co-maintainer?

Cheers,
Andrei

Mark thanks for adding me to the list of maintainers for EF.
I'll provide a patch later this week for this issue.

I started working on this and I can confirm that we need jQuery >= 1.3 (aka jquery_update 6.x-2.x) otherwise the triggered event for the datepicker won't bubble up the DOM. See jQuery 1.3 Changes

With jQuery < 1.3 this won't work for datePicker fields:

$(document).ready(function() {
  $(document).bind('change click', function(event){
    if(event.type == 'change') {
      if($(event.target).is('input, textarea, select')) {
        if($(event.target).parents('div.editablefields').length) {
          Drupal.editablefields.onchange($(event.target).parents('div.editablefields'));
        }
      }
    }
  });
});

This is a first draft of the patch (against latest dev snapshot) of what I had in mind. It seems to be working pretty well for a first patch (I didn't test it thoroughly though). Please do test as much as you can.

Please also note that this patch tries to handle only the client side performance issues so try and measure only the time spent for rendering the page on the client side only not overall.

How it works:
1. For clicktoedit and editable_html formatters: replaces the default event handling with a global delegated event handling mechanism as described in #9.
2. For AJAX editable fields the default behavior applies.
3. If there are a lot (currently set to 25) of editable_html textareas generated the module will include a special js file (editablefields_overrides.js) that will override the default behavior for textarea resizing: in this case the resizable grippie will appear only if you click in the textarea itself. We can implement the same strategy for datepicker fields (ie. only when those fields are focused the event handlers get attached).
4. The user can't have more than 1 active clicktoedit datepicker field (I hope I can fix this in the next patch though).
5. Adds jQuery_update as a dependency (as per #16).

Before testing this:
1. Make sure you have jquery_update-6.x-2.x-dev installed.
2. Apply the patch or download the attached patched module.

Added the "[edit]" link back. Now the display/hide behavior is handled directly by CSS and not JS. The edit links will appear by default in all the cells that have no content.
It won't work on IE (no div:hover there) of course so that needs Js handling.

Collapse on blur functionality for clicktoedit fields is now back in.
I feel this last patch gets us very close to a commitable version.
I'll keep testing tomorrow.

Edit: I corrected "not back in" into "now back in".

Please note that labels for checkboxes/radios not working is not related to this patch. #969754: Clicking on labels doesn't work for checkboxes and radio buttons will go in after this patch.

I commited this to 6.3 dev branch. A 6.x-3.x-dev snapshot release will appear in the project's page in less than 12 hours.
I'll mark this as fixed as the above patch does fix the performance issues on the client side. If there are any bugs introduced by this patch please create new issues for them.

Thanks,
Andrei

was this applied to 2.x-dev?

can patch in #19 be re-rolled.

It doesn't apply to the latest 6.x-2.x-dev release