I'd like to support field-groups, so we could have editable, computable and normal fields all 'grouped' together. These would form the 'lines' in a spreadsheet...

Nice plan, but how to make it work?

The way things hang together right now, fields within a field-group marked as 'editable' will indeed be editable, however, the option within field-group to add a new 'line' will be missing... Maybe this feature has to be added in the fieldgroup module?

Comments

markus_petrux’s picture

markus_petrux commented

Related issue for the Multigroup module in the CCK queue: #119102: Combo field - group different fields into one

For the 'Add more values' button, you may look at content_multigroup_add_more() in content_multigroup.module ? If it doesn't work directly, maybe you could create a separate function here based on that one?

Then, the function content_multigroup_add_more_js() could be used as an example on how to build the part of the form that is related to a complete subgroup of fields (a delta).

markfoodyburton’s picture

markfoodyburton commented

I guess there are two alternatives:
1/ If anything is marked as editable within a group, then the group should magically become editable..
2/ We should provide an 'editable multi-group' group type...
I think (2) is slightly cleaner (though not as easy for the user?), but then I'd have to replicate (or call into) all of the fieldgroup module.... not hard... but...

Whats your thoughts?

Cheers

Mark.

markfoodyburton’s picture

markfoodyburton commented

Meant to say ... excellent, thanks... I'll look into using this :-)

markfoodyburton’s picture

markfoodyburton commented

I thought at least editable fields within a multi group world work --- I thought I had one working - more fool me... I was assuming much, and it's not the case...

So - we're not even at square one on this. I still dont like the idea of rendering the whole form, I prefer the way it's doing things now, but ......

So - I'm going to try and get editable fields working for the fields in a multi-group initially - then see if we can add the 'add more' option....

Cheers

Mark.

markfoodyburton’s picture

markfoodyburton commented

Ahh, now I see what you mean about the 'div' trigger mechanism.... I'm not so sure it's the div thats the problem, more the 'symptom'....

I believe that actually multi-groups is right to be a group of fields, not a field of fields. The reason this is important is that, if it were a field of fields, then, the 'field' would be marked editable, the entire field 'form' would be generated, everything would work (with editable fields as it stands today).

However, this isn't quite what we want (!)

We want a mix, within a group, of some fields editable, some fields computed, some fields printed, etc.

So - building a single form for the whole group would not be the right solution (and, this points to why I think building the 'node edit form' and then trying to extract the right parts of that would also be very painful).

Cut-to-the-chase....
As it stood, the trouble is (with the 'div'), we dont know which 'delta' we are dealing with - so the result would be to over-write the whole field -- ops.

Actually, this pointed to a bug in the code anyway - multiple fields would always overwrite field instance '0' and 'zap' the rest...

So - the solution to is maintain the 'delta' along with the field name etc... thats done, and now both multiple value fields (normally) and field groups should 'work'...

(see latest CVS snapshot)

However - this still leaves one problem (of course) - the problem of adding more values to a multi-value field, or more sets of values to a group.... but - Markus has pointed me to something for that - but... see next post

Meanwhile - can somebody give the latest code a good thrashing on multi-value fields of all sorts?

Cheers

Mark.

markfoodyburton’s picture

markfoodyburton commented

Dang.... the content_multigroup_add_more had a problem - which it solved - in order to get things to work, it re-output the entire field in order to make sure 're-ordering handles' etc worked...
Thats fine for a form for the entire field, but....

My 'dream' : we have a 'spreadsheet' of rows and columns.
the 'rows' are fields in a multi-group.
the 'columns' are subsequent value sets in a multi-group.

The point being, for each column, we want to be able to say "this one is editable, this one is not, this one is printed out, this one is computed"....

So - now we have a problem - the 'add more' button wants to add a new 'row' to the spreadsheet. But, we would also like to be able to re-arrange the rows, etc... In order to make that happen, it looks like the whole thing has to be 'editable'.

In which case, we end up treating the multi-group-of-fields like a field. It would maybe have been better to have it as a field or fields in the first place....
But - thats not the ideal solution....

Net result - we're caught between rock and hard place as far as I can see :-(

We either treat the whole group as a field (in which case, I'd like to see multi-group become multi-field), or we treat each field on it's own (in which case, row re-organising and row additions becomes a real nightmare because we will have to solve the problems that multi-group decided couldn't be solved.....)

So - time for some compromises:
1/ we could detect that there was an editable field inside a group, and provide an 'edit this whole group' button. i.e. start out with editing the fields, and revert to the whole group if the user requires it... (Maybe we could add a permission or some such to make this available only to privileged users?)
2/ we could add a 'add more' button that did not enable the re-organisation of the rows, so the behaviour of the columns could remain the same?

I'm guessing that between (1) and (2) 90% of the use cases would be covered - I know that my use cases fall into (2), though I have one use case that would fail, being neither (1) nor (2).

For (1), Somehow, when an editable field is rendered, if it happens to know it's part of a group, it needs to send a message through to the javascript. The javascript should then insert an 'edit this group' button on the group. Pressing that should call into the whole content_multigroup_add_more framework, replacing the entire group content I guess.
Most of the back-end submission processing should still work fine, except either
a) the whole group needs to be submitted together (in which case, the delta value is not appropriate, and some other signal needs to be given to let the back end know it needs to save everything) - this will cover re-organising rows. or
b) each field that has been updated (i.e. re-organised, or changed) needs to be submitted separately....
(in this case, the back end will remain unchanged, but the javascript would have to take care of things - and hence cover row re-organisation)....

(2) is probably not too hard, in this case, the javascript should insert a button "add new row", and the result should be to call into the content_multigroup_add_more framework, getting a new form entry. 'Submission' is easy, as it's "just" (b) above....

Doing (2) would seem like a pre-cursor to doing (1) anyway....

When generating the new 'row' form entry, We'll have to take care to add a 'editable fields' div to each field (the right 'delta'), but this shouldn't be too hard?. It may take a rewrite of some parts of content_multigroup_add_more_... ?

So - to re-cap: We're not going to get the perfect solution :-(
But, we can get a reasonable solution.
Steps:
1/ Find out if a field is inside a multi-group.
2/ If it is, arrange that the javascript adds a 'add new row' button to the surrounding group when a field becomes editable within it.
3/ Re-work the content_multigroup_add_more code (or start from there) to provide a 'editablefields' set of fields...
4/ add a 'make everything editable' button.
5/ use the content_multigroup_add_more code to provide the entire group....
6/ either change the JS code, or the PHP or both, to handle the submission properly...

Something like that?

Looks like HARD work....?

Is it worth it? This looks like a FANTASTIC (and fundamental?) addition to Drupal, it looks like the right way of implementing everything from a shopping cart to an issue queue, but.....

Comments?

Cheers

Mark.

markus_petrux’s picture

markus_petrux commented

Dealing with multiple value fields is not easy because there may be fields that don't use 'value' for the element name, so you cannot assume that all multiple value fields work in the same way.

The same problem happens with the multigroup module, where fields are moved from field->delta to group->delta->field in the form structure, the required attribute works different, checkboxes may become radios, multi-selects may become single-selects, etc. Note that the multigroup module is not compatible with all fields. Fields that deal with multiple values themselves should implement a couple of content_multigroup hooks (see the feature request to the content taxonomy module for an example). The reason for this "compatibility check" is that the multigroup module needs to revert the changes to the form to the original state (fields back to field->delta) so that field validation and submit handlers work, which is pretty difficult to achieve. Look at after_build and pre_render FAPI handlers of the multigroup module to see this.

These processes may be pretty complex due to the different combinations of fields that exist. That's why I thought one possible way to resolve this was to work with the whole node edit form, but only expose to the user the part that matters for each field being edited. Even then, there may be situations where it is not really possible to do what you want.

Another thing that I would suggest is that maybe it would be nice to think about a different method to setup which fields can be edited or not. The current method, using foematters, restricts the use of other formatters that one would need to use. Maybe you could implement this by altering the field settings form?

markfoodyburton’s picture

markfoodyburton commented

For the 'value' thing.... not sure which bit your getting at:
The $_POST may (or may not) use 'value', but the widget should process whatever is there. Except to put the empty value=>NULL in, in the case of an empty checkbox, we dont touch this value, so I think this is OK?

The form_state array which is built has a 'values' element in it, but I think this is built by CCK itself from the results of calling the widget/field for processing? So I think it's OK to assume this?

The field's normally use [0] for the first of multiple values - I thought this 'convention' was now built into CCK so that it would be safe to assume that all fields would be encoded this way, hence it would be safe to that $form_state['values'][$field_name][0] would be the fist (or only) value of $field_name?

I used to rely on the actual 'value' field within this, and check its value, but I'm not doing that any more, as I'm using the CCK framework to build the form_state array correctly...

So - which bit am I missing?

For the main comment you make - I agree. As I said above, we're between a rock and a hard place. I'm not sure that building the whole node form would help you - I think it solves a different problem - but you still need (I think) to be able to select which elements of a multigroup you want to be editable, and which displayed 'normally'.... and I dont think basing this on the node edit form, or not, helps :-(

For the 'formatter' thing - the reason I _love_ using the formatters is because it means, for instance, I can build 2 views of the same data, one with some elements editable, and another with different (or no) editable elements. This is hugely powerful as you move through a workflow or whatever...

So - I like using the formatters, but, I agree (as I said on a release note somewhere I think) on-day, somebody is going to say "But, when I mark a field as editable, but the user has no permission to edit it, then I get the default formatter, which isn't pretty"....

For views, we can solve this with multiple views... though it's not the most elegant solution. For nodes, there is currently no solution.

Ideally, maybe in D7? I'd like 'formatters' to be an ordered list.... top preference, next preference, etc... then a formatter can agree to operate on the node, or, if it can't, can pass down to the next on the list...

Cool - but - is it worth doing?

markus_petrux’s picture

markus_petrux commented

By "fields that don't use 'value' for the element name", I was referring to the problem pointed to by #353110: Single on/off checkbox and Check boxes/radio buttons CCK widgets. The on/off field now works, but what if the field element is not 'value'.

if (!isset($_POST[$field_name])) {
  // This works for some fields, but not for others!
  $_POST[$field_name] = array('value' => NULL);
}

In this context, 'value' is used by text, number fields with optionwidgets. Good. Now, try for example with userreference_buttons with multiple values (will use checkboxes). Works? Nope. You should use 'uid' rather than 'value' here (see function userreference_buttons_process). Since it depends on the widget implementation, you need to get this programatically.

Test with all possible fields out there and see if this module works ok on them all. Maybe you find other pieces that need attention. Also try playing with the multiple value for fields, and see if it all works. Here you need to deal with deltas yourself, but some fields are configured to manage their own multiple values. Once you know the editable fields module works in all these scenarios too, not just the multigroup module, then it will be great, heh.

Back to the formatters... yes, the problem is that. If you wish to set a field editable, then you cannot choose another formatter, which might be necessary for some kind of fields.

Back to multigroup module... here you cannot simply use content_field_form() to build field form elements. Look at content_multigroup_group_form() and analize how it's done to see what I mean. For the editable fields module, you will have to know how to build the form element for each separate field/delta. Once this is done, you'll have to know how user submitted data should be reflected in the database. But in the context of the multigroup module it's all managed assuming it all happens for the whole multigroup. So it's not possible to just issolate the job for a single field/delta for you. Well, I'm open to suggestions to change the multigroup module to easy this. For the moment, I don't know how, honestly. It took me a lot of days of work to get the multigroup module working with as much widgets as possible (more time that the project I'm working on expected), and still it is not compatible with all which is why modules that deal with their own multiple values should implement a couple of hooks to tell the multigroup module they are compatible. There's nothing writting that cannot be changed, but you should know what to change and why. I'm open to suggestions for the multigroup module. But you should first try that for yourself and confirm it works.

markfoodyburton’s picture

markfoodyburton commented

for the array('value' => NULL);
I dont see why we need this at all, anyway... The serialiser will return (worst case) and empty array that we put into the $_POST. The CCK modules would have (or could have) got the same response from a normal form submission I think?
In which case, they should deal with this 'normally'. We shouldn't need to put 'value'=>NULL in there, because, is some cases, there would have been no 'value' in there anyway?

So - I'm confused why we need this? I initially thought it was because the serializer doesn't give the same results as a regular form submit, but I dont think thats true???

For formatters, I agree. I think the advantage of using formatters outweighs the disadvantage though.

For the multi-group module - I agree too. I think the current set up is 'ok' as far as it goes, but, I think your absolutely right, if people want the ability to use editable fields to edit the whole group, as the multigroup module provides, then it's not trivial at all...
My feeling is - before we go there - I'd like to know who needs this, and to see some example use cases to make sure we are attaching a real problem.

2ndmile’s picture

2ndmile commented

Did you ever make any progress on this.? I am wanting to have a multi-group with a single checkbox that would be 'editable' on the node form. When I set it up and add 3 lines only the first one is editable, the other two disappear (display:none).

Equinger’s picture

Equinger commented

subscribing

glennpratt’s picture

glennpratt commented

For what it's worth, I'm using CCK 2.x with the multigroup patch and it seems to work fine except for an issue with old nodes (the fields don't show up until the node has been saved once) with editableviews.

mengi’s picture

mengi commented
Issue summary: View changes
Status: Active » Closed (won't fix)

Per https://drupal.org/node/2148735, 6.x is longer maintained so issue is closed. If you wish to be a maintainer of the 6.x branch please create a new issue.