Enable individual fields to be editable

For one, and this is fairly minor, it's not quite adhering to code style.

Let me know whats wrong, I'll fix it - I read through the coding style guidelines and nothing jumped out...

For two, and this one is killer, you're hardcoding this to CCK, which is something Views tries to avoid. What needs to happen here is that it needs to be turned into more generic handlers that CCK can respond to (so it needs a second patch to CCK to implement that portion, unless CCK's handlers already return adequate information in which they can be used directly). That would make it so that any module can put up form elements.

I agree, - yes, ideally one module would have nothing to do with another. There is actually a part of the code that could be changed to add in the ability to make use of other modules - it's hard coded to only work with CCK right now, and core "node" items, or any others are dropped with a warning.... I'd say we should start with this, and aim to extend it as soon as we find other "node types" that would be useful? If CCK is to be adopted in the core, then I guess the question is not relevant anyway?

For three, how well does this integrate with http://drupal.org/node/103171 ? That effort has been going on for some time, and I am thinking that a useful patch is going to come out of that at some point here. I was hoping they'd have more progress by now, but I've been lax in encouraging them to continue the work. So I want to make sure that one or the other effort does not get completely derailed. I'm going to put a pointer on that issue to check out this issue so that we can get efforts put together.

So, the only person who got back to me about this when I originally posted was Mark. And, as I commented on the page, thats where I started looking. However, as best as I can tell, his patch is orthogonal to this one. There is also "editviews" which is also aimed at some of the same sort of functionality. But I think the use case, and the eventual functionality you need is different.

In my case, I am looking for something that I suspect will be relatively common, a view of some CCK enabled nodes, in which I can provide my user the ability to update, probably only one field....
Examples:

• A "shopping basket" where you can adjust the number of items (but not their description of unit price)
• A "todo" list, where you can update how far through you are in the task (but you would use the full node edit to change the text)

As far as I can tell, none of the other modules and patches are aimed at these use cases.

I am REALLY sorry, I made a mistake in the previous patch, and the important patch to the views_ui didn't get included!

In terms of trying to factor this code OUT of the views module itself, I had a look at this.

There is a "core" requirement that the underlying database, and database access functions have the "editable" field in them, but this is a very small patch.
The views_ui.module could be "branched" to be a views_ui_editable.module, though I see very little point in doing this?
I suspect it would be possible to move some of the collection of rendering information down into a "theme", but this would seem to me to place a very heavy burden on a theme, with little gain, other than to make the theme dependent on both views and cck, rather than to say that editable functionality depends upon CCK (though CCK is optional for views itself). I believe CCK is optional for views itself, as things stand, in that if CCK exists, then the views module is capable of doing things (like displaying CCK fields) that it would not do otherwise. It seems to me that the editable functionality is nothing more than an extension of that optional requirement.

I would love to hear other peoples views on this matter, and more, if people disagree, or have other ways of achieving the same goals, I'd love for them to edit the code....

Thanks for the feedback!

Actually, I am remiss in not telling people what I am currently up to.

First, I discovered a problem in the way I was treating the fields, so I have been re-working bits of the code.
Second, I wanted to include a "new" form - like editview has.

So, right now, I have gone the route of creating a new module, and - hey presto - I have done exactly what you have suggested and made it so that it's a formatter.

The issue is: Ideally, if somebody comes up with a "format as a long line around the edge of a screen" formatter - you should still be able to say "And I want that field to be editable". - So, my opinion is that this is a second rate solution. In the case you mention - where sometimes you want a view with, and sometimes without an editable field, whether you do this with a formatter or without, you still need two views. In one view you select some fields editable - in the other you dont.

My idea is that I will patch JUST the cck module to make it so that all CCK widgets present an editable "option" to the view module - this way, I wont even have to patch the view module. - I'm not there yet, and I dont know if this will work - however, again, it is a second rate option. While my view is that there is no place for non-cck objects in the world, and I'd like rid of title and body, none the less, they exist, and they should be editable via this means - however - since I dont care about those, I wasn't going to put the work into making them editable anyway, so this solution works for me....

On the jquery stuff and views calc -
Yes and Yes.
My plan was to get it working - still not there - I have some issue with setting values in the "new" form (I want the filters of the view to be used as the values in the "new" form, and it's not working for me yet, but I'll get there I'm sure :-))
Then, next - clean up the code
Then, next - make it jqueryable - for speed and elegance
At that point making it a spreadsheet with vcalc sounds like a real cool plan :-)

I have created a new module that does 99% of the work of this patch, So, the patch is no longer needed, thanks to merlinofchaos to pointing me towards the plan. It has a feature I dont like, namely that the "edit-ability" of a field should not depend upon the view type, but in order to process the options, it seems that having an editable table/list is about the only choice. Maybe with views 2 this might change? Anyway, it hangs together OK, so PLEASE try this module out ( http://project/editablefields ). It still relies on a CCK patch, which I dont like, but as yet, I dont see a good way round.

As for integrating with viewcalc, it's on the to-do list :-) - as is making the thing more AJAX'y, to speed things up for the user.

At present, the module displays a form at the bottom, and tries to guess at defaults based on the views filters/arguments, I hope it works :-)

As the #7 says, there was not a need for the patch to views in 5, the 'editablefields' module did the job on it's own.

HOWEVER, a lot of people seem to be using editable fields, ( and I have to say, I am in the process of putting together the simplest of web sites, and, for even this very very simple case, I seem to need something like editablefields :-( )

So - I would __LOVE__ to see editablefields support natively (AND PROPERLY) in Views/CCK. The editablefields module, I consider to be a plaster, not a great solution :-(

Any hint's tips, ideas well received, and I'm happy to help a little if I can.

Cheers

Mark.

Sounds like we're all in agreement, I'll work with merlinofchaos off line, if there is anything I can do... But for View's 1 and Drupal 5, this is essentially closed.

Cheers

Mark.