I thought before trying the editview module was that it would show only once every field all the nodes of the view, a bit the way the image_import.module does it (eventhough it's not a view): admin-content-image_import.png
from #98363: doesn't display nodereference fields for editing, under comment 5

As it's not the case and a row is showed for each node, which concretely can't allow building big requests, this "Same editview fields for all nodes" feature would have saved time, place and server ressources.

Yet I guess this falls beyond the reach of a view... but I ask anyways, if there could be any chance...

Comments

Frodo Looijaard’s picture

Frodo Looijaard commented
Status: Active » Postponed (maintainer needs more info)

I am sorry, I do not understand your problem.

Has this to do with labels being displayed again for each row (see #583542: Heading displays over each row)?
Has this to do with node reference problems (see many other issues, among them #635080: "Add another item" adds to wrong node, #609644: Nodereference field not showing up in D6, #426322: Does this module work with node reference CCK fields, #296744: Select list for parent does not show up in editview, #296662: Buttons, #264855: Doesn't seem to work with multi-reference nodes, #98363: doesn't display nodereference fields for editing)
Or have you something completely different in mind?

gregoiresan’s picture

gregoiresan commented

Same problem told here : http://drupal.org/node/727106

The thing he wanna say : why duplicating as many node rows as comments instead of a node row with all comments attached to ? Something like the taxonomy 'show all' field or the Image grouping option (avoid duplicate nodes) ...

I am digging into forums to find out but I have no alternative solution to the one shown above at the moment.

Frodo Looijaard’s picture

Frodo Looijaard commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

At comment #2:
at the moment editview tries to keep things at least somewhat simple by using the normal node form and hiding the unused parts. This is a relatively robust solution that at least gives us some chance to let add-on modules work. The downside is, of course, that the pages grow quite a bit. Though I could theoretically see how to do this without, this will probably not be implemented in the foreseeable future. I have marked this as a potential feature in my TODO file.

But it seems the original submitter had something quite different in mind if I look at his question again. He does not want a row for each node but a multiple input field or something like that. It seems to involve a basic misunderstanding about what this module is about.