It seems that Editablefields provides functionality people like - and changes, to a degree - how people interact with web sites - great.

Only the module itself is not great.

It's very simple (whcih is good), but there are too many exceptions when dealing with CCK field types.
e.g. check-boxes - when serialized - get no content. When the CCK field form is run, the missing data is filled in with the last value held. Net result, you can switch it on, but you can never switch it off.
This isn't CCK's fault, nor is it 'option widgets' fault per-say. Nor is it the serializers problem, nor the editable fields module - it falls into no man's land.

Likewise, multi-valued text lines fail because they are handled by the CCK core, but the editablefields module doesn't know about the extra 'empty' line that should be added to allow the user to add an extra field (because thats handled in the core, not per line, but per field)....

likewise, I'd live to see much better control about how things appear. Like - if you can edit something - fine - editable - otherwise, I'd like to be able to select which formatter to use, not to just get the default...

All in all - it seems to me, the best way of dealing with this would be to take editablefields in, under the 'wing' of the CCK - and indeed - eventually, I hope - CCK should be in drupal core....

But - I personally dont want to go there, and I dont think the editablefields module is constructed in anything like the right way to be a 'core' CCK service. Indeed, I think some major thinking would be needed to allow for a great 'editablefields' functionality through CCK....

So - this is a feature request. I'm happy to help, as much as I can - but as a kick off, I'd like to collect ideas about how this could be done well, rather than the solution we have now...

Cheers

Mark.

Comments

markfoodyburton’s picture

markfoodyburton commented

As examples, see: http://drupal.org/node/505774 and http://drupal.org/node/353110

markus_petrux’s picture

markus_petrux commented
Version: 6.x-3.x-dev » 7.x-2.x-dev

I'm afraid we're all too busy to change too much CCK core for D6. Also, quite late in the life cycle of CCK for D6, I think. Moving to D7 for consideration...

markfoodyburton’s picture

markfoodyburton commented

good plan.
(BTW, I _hope_ there isn't too much of CCK that need changing... )

Cheers
Mark.

_paul_meta’s picture

_paul_meta commented

I'd love to see a solid integration of cck/views/editable fields in D7 ... having used drupal for several years now, it was editable fields that really set me free to create content workflow screens to suit client's needs perfectly. currently in D6, editable fields is good, but it has issues with multiple values, image and file fields... it would be great if future releases allow this to all happen smoothly. building custom workflow screens in views with editable fields allows me to keep the user from ever needing to use the node edit screen which has many advantages. i'm happy to elaborate further about this and am open to financial support of integrating these modules better (would be nice if it could get back-ported to D6 aswell!)

thanks!

markus_petrux’s picture

markus_petrux commented

@markfoodyburton: Maybe it is possible to properly support any kind of field already, with current CCK2 or CCK3 for Drupal 6.

I had a request to build something similar to Popups Subedit module, but based on the Modal Frame API. Both modules allow you to edit a fieldgroup in a popup that can be opened from the node view page. Mine can be found here:

- Modal Frame CCK Editor.

I coded it in a way that it can also work when a fieldgroup is rendered using fieldgroup_view_group(), and that includes support for Panels too.

And I also added the ability to use this feature for fields in node view. This one does not work for Panels or Views because the trap acts during node view rendering process for fields, which is a different method than the one I used for fieldgroups because there's no easy way to intervene whenever a CCK field is rendered in Panels or Views, unless you use a CCK field formatter for that purpose, which is what EditableFields module does.

However, there's a common place all fields execute when rendered in Views or Panels, and that is content_format(). If there was a way to intervene when content_format() is executed, there would be no need to use a specific CCK field formatter to add a new behavior, so I posted the following feature request to CCK, that proposes to add a call to drupal_alter(), so you can change the $element before it is processed by theme() inside content_format().

- #687296: Allow external modules intervene whenever a field is rendered using content_format()

Then... the other critical part is the way how the form to edit a field needs to be built. Here, I would suggest you to take a look at the code in Modal Frame CCK Editor. The whole node edit form is build in a way that only the required form elements are visible. That way the node form is build using the regular flow. The only tricky thing that needs to be done is render only the parts that are required to let the user edit the requested field or field group. This method works pretty well on a modal frame. I'm not sure how well it could work for EditableFields however, because that one needs to alter the DOM of the current page which adds an additional level of complexity. But that's something out of the scope of CCK itself, I think.

In summary, I think that current CCK allows you to support edition of individual fields, so maybe there's no need to add anything.

markfoodyburton’s picture

markfoodyburton commented

I think your probably right, there are maybe other ways of implementing editable fields,
but issues like http://drupal.org/node/505774#comment-2437832 do cause pain. The CCK API to provide the editable version of a field is fantastic, and I (personally) prefer it to rendering the whole node in edit, then taking the parts out I need - and even then - finding the parts I need would be hard.

So - I dont know - you are probably right, there may be other ways of doing things, but I can't help feeling that to have a field 'editable' is something quite fundamental, and I'd like to see it in the core. I'd like to see it as an option separate from the field renderer chosen because, I think you should be able to use permissions selectively to show the edit to some people, and the rendered field to others.... This would (I think) change the way the API in CCK and Views would work (because you'd need an 'editable' check button somewhere). You also need to take into account per-field edit permissions etc.... All of that needs to be thought out nicely I think.

I agree with you, it's possible to put something together as a module, but, I think the users interface, the functionality, and the elegance would be greatly enhanced if it was in the core somehow....

Cheers

Mark.

karens’s picture

karens commented
Status: Active » Closed (won't fix)

There is really nothing left in CCK for D7 except the field migration code, so nothing we can do. Editable fields will have to find a way to conform with the way that core handles fields, one way or another.