The following node has a short overview of the thoughts behind this patch,
http://drupal.org/node/155253

The groups page:
http://groups.drupal.org/node/4891
links between this patch and the piece needed in the views module to make use of the patch.

Basically, this patch refactors slightly one function in the cck code to expose a function that can then be picked up by the view module in order to make each field editable (or not).

I hope people find it helpful :-)

CommentFileSizeAuthor
#1 editablefields_cck.patch4.87 KBmarkfoodyburton
editfields_cck.patch4.17 KBmarkfoodyburton

Comments

markfoodyburton’s picture

markfoodyburton commented
StatusFileSize
new editablefields_cck.patch4.87 KB

Please use the following patch which enables independence from the views module, and use the editablefields module ( http://project/editablefields )

markfoodyburton’s picture

markfoodyburton commented

that should be http://drupal.org/project/editablefields

karens’s picture

karens commented

There are basically two things in this patch, one small and one much more significant.

1) You want to add a field 'editable' to all CCK fields if your module is enabled. This is a problem for several reasons:

a) If someone creates a field and later enables your module, and then creates some data and then later disables your module, the CCK methods of keeping track of what fields have what values will be a complete mess as your value appears and disappears from the field.

b) We don't use any 'if (module_enabled)' code in CCK, except for Views and path auto because those two are so widely used. For all other modules we ask for module developers to find a way of using hooks in their own module to accomplish things. If we added in 'if (module_enabled) for every module that does anything with CCK (and there are many many many requests for that) the CCK code would become really unwieldy. I know you'd prefer to have that value automatically there, but if there is no reason for it to exist outside of your module, it's hard to make a case that it belongs in the core code.

The good news is there is already a way to do this. Formatters were designed to be altered by other modules, so you can create a hook_formatter_info() function in your module and enable your editable field for all the CCK fields you want to support.

2) The second, and more complex, part of the patch is a change to the way CCK handles widget_invoke. It may well make sense to break this up so it is invoked for every field, but it also has the potential to create all kinds of maintenance problems if it introduces any bugs. On top of that, the widget handling is probably going to be completely rewritten for 6.x (or at least have some significant changes) so making any big changes for 5.x is not high on anyone's list. We're already having trouble finding enough time to keep up with the issue queue and get the 6.x port working.

I'm very interested in what you're doing with your module, and you know I already offered to try to incorporate it into Views Calc, so I'm not trying to be negative, just realistic about making changes to CCK that make it more difficult to maintain. And I'm open to arguments/feedback, especially if yched or dopry have any thoughts.

markfoodyburton’s picture

markfoodyburton commented

I'll check up on the hook - I would prefer that mechanism, sorry I didn't find it myself.

For the bulk of the patch - the only alternative is to replicate the code in the module - of course I can do this, but it's not so nice I dont think. Anyway - maybe we should do this to make sure it's stable. (BTW, you'll see the patch is really just a factoring of the code, it doesn't change anything, just moves it about a bit)

For 6, I hope you can provide functions like this straight away, then I can remove the code replication :-)

I'll work on the module again over the next few days :-)

markfoodyburton’s picture

markfoodyburton commented

(Sorted the hook - easy, once I saw through the mist)

So, I have copied the code from cck into the new module - replicating code is a bad thing, however, given the state of the world....

This patch is no longer required.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Needs work
karens’s picture

karens commented

The 6.x port has changed the way widgets are handled in a way that I think will work for your purposes. There is a separate function to add a single field to a form that you should be able to invoke. See http://drupal.org/node/157176 for info on the state of the changes.

markfoodyburton’s picture

markfoodyburton commented

I think this looks perfect.

One of the motives for the code I have written was the ability to add more items to a list. The new way of handling multiple values will ease that. However, building a "list of nodes" is still useful - which really requires a view to find the right nodes - so a "multiple node-reference" with a link to a view, and a means for adding a new one would be ideal. - this is basically what I've done in the module I've written, but it addresses the problem from the "views" end, rather from the "cck node-reference" end.

I think, in the fullness of time, when I get round to moving across to 6.x, changing this and building a mechanism for handling multiple node references would be really nice.

Thanks a lot for the work on 6.x, it looks really good.

karens’s picture

karens commented
Title: Enable individual field widgets to be displayed, eg. from a view » Add editable field for views
Version: 5.x-1.x-dev » 6.x-1.x-dev

Changing the title and version to reflect the remaining issue, now that the 6.x code allows for individual field elements.

markus_petrux’s picture

markus_petrux commented
Status: Needs work » Closed (won't fix)

Pretty old thread and editablefields is already able to do its job.