Extremely slow in large view tables

Would love this.

A master save button would be great. Otherwise could ajax traffic be reduced to data involving a single field?

Is that what this module is accomplishing?

http://drupal.org/project/editablefields_as_link

you probably need vbo

I'm not sure VBO would accomplish that, but perhaps an alternate field display handler that skips AJAX and utilizes Views 3's form view API, which I'm pretty sure this module is not using. That would be a pretty big change in strategy and is probably more appropriate for a new module that only targets views.

I have just been stepping through the code after some ajax issues and have to say: this module is not for use with views. The amount of form data being sent through system/ajax is not only huge, but the work getting done on it after that is nearly all unecessary for saving a single field in a view. We need a different solution. dafader do you have any idea how it might work with views api?

Also can we get the front page to warn people of this? Might save a few trips down a dead end road...

rafaqz - some general ideas, yes. Views 3 introduced a new form api that is still fairly unknown and underused. Here is some ideas to get started:

http://views-help.doc.logrus.com/help/views/api-forms

Maybe let's continue this conversation elsewhere? :)

But I agree about some kind of warning on the front page re: views. I've been testing this module for use with views and so far it's not terrible (the views I'd be using it on generally have less than 20 ros) but something much lighter-weight would probably be much better.

Yes I've noticed the same issue in views with 50-100 rows. Interestingly, performance was better when doing similar things with Drupal 6 and views and editable fields.

Its a real shame as this is a great module and it makes a lot of sense to want to make views with certain fields editable - the workflow difference from editing/saving each node individually is considerable and adds a whole new level of usefulness to drupal.

Would love to see how this issue progresses, either in this module or for a new module.

urmm..
Installed and tested this module few days ago, found it great making views with editable fields, until now just testing, so still have only 2 views rows, but my intention was to build a list of 1000+ rows.

Reading this thread/issue makes me think that this module - at this moment - is useless if displaying i.e. 1000+ rows?

So let's say you have a views page with 1000+ rows with editable fields. And you edit one field in one of the rows and click 'enter'. It goes bananas?!??

It's quite like you describe it. I found this module extremely useful for editing views with a handful of fields. For example, a view with 6 rows x 6 fields works great. The same view with 100 rows x 6 fields throws AJAX errors as soon as I change one single field. Because of AJAX you don't even need to click "enter".

The same view with 100 rows x 6 fields throws AJAX errors as soon as I change one single field.

And how would be the best solving this "AJAX errors"-problem?
Also, I don't exactly understand why these errors occur.. By editing a single field in a views row we are editing only one single node, so why would the edit process be affected by the fact that we have 6 or 100 rows?

I have no idea. I did not analyze the traffic produced by the module, but it seems that maximpodorov's description in the issue summary and #7 is right: it just looks like all the field data is sent via Ajax even if you just change one single value. Hence, folks here are suggesting a single save button.

It looks like there have been substantial changes to the module to make it entity-agnostic so the patch doesn't apply and the logic has changed; however, it still looks like this performance issue exists.

[wrong thread]

some years went by :( the issue still is an issue- having some hundreds views-rows containing e.g. a couple editable checkboxes each will be very slow AND generate ajax errors due to using thousands of input vars and so on....

@thommyboy any suggestions? I'm actively working on this module and would love to make performance improvements where possible.

Hi Joel, good to hear someone works on it ;)

Actually I can only use "editable/link". A couple issues otherwise (inside a view)
- having a couple checkboxes set to editable per row and some select boxes
- clicking a checkbox ajax wheel turns very long (got 250 rows each having 5-8 editable)
- ajax error 500 after that (but value gets stored)
- in console I see [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. send @ jquery.min.js:6
- php error in log (max_input_vars) increased those to 50.000 ;) to get rid of it
- trying to use a pager isn't possible because it seems all editable fields get rendered no matter if the row is currently displayed :(

I'm not an ajax guy but wonder- it seems that all visible editables (?!) are put into an ajax request also if only one at a time get's changed? I think changing that (if its true) would help avoiding errors and improve performance but thats only a guess