In 6.x-3.11, in webform_hooks.php, the group feature is described as follows:
// If this field allows other fields to be grouped within it (like a
// fieldset or tabs). Defaults to FALSE.
'group' => FALSE,
this is misleading. group is for components that allows other *components* to be grouped within it. it is *not* for components that contain multple levels of nested fields (like, say, a component that provides two fieldsets, each containing some fields).
if you enable group for a component that contains regular fields, instead of components, then you will suffer data loss, and any data you do save has cid 0. (this happens when _webform_client_form_submit_flatten() calls webform_get_cid() on an item that is not a component.)
i found this out the hard way, as did NicolasH in #965068: Component with multiple fields? :)
i will post a documentation patch today or tomorrow (will provide for 7.x assuming 7.x has the same issue - i haven't checked yet)
thanks for an awesome module! the 3.x API is totally saving my bacon.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | update_group_documentation-1189964-3.patch | 4.16 KB | firebus |
| #1 | update_group_documentation-1189964-1.patch | 4.03 KB | firebus |
Comments
Comment #1
firebus commentedhere's a patch. i changed "field" to "component" in the comments on each feature. i added a section about components with multiple fields, and made another minor change to the wording of the features documentation,
Comment #2
quicksketchLooks good, but this information doesn't really seem appropriate for describing hook_webform_component_info(), seems like it should be in _webform_submit_[component]():
I also don't think fieldsets is really a common example. Components like "date", "time", "grid" and "file" use the save hook to flatten or cleanup their data though none of them use fieldsets.
Comment #3
firebus commentedquicksketch, thanks for your feeback!
i agree that _webform_submit_component() hook is a good place for this paragraph.
but i don't think that date, time, grid, or file demonstrate what i'm talking about, they do have some flattening in their submit hooks, but it's a different kind of flattening.
of these four components, only file has render hook that returns an array of fields, instead of just a single form field. i'm trying to explain how to handle custom components that contain deep arrays of form fields, as opposed to single fields or a single array of fields.
let me try to explain it better, at the risk of being waaaaay too verbose.
let's say you have a simple custom component that provides a single form field. its render function returns an element like:
if you submit a form with this component it will generate one row in webform_submitted_data. grid, date, and time are all like this - they render a single field. for date and time, the value gets expanded into an array, and then re-flattened into a single value.
now let's say you have a more complex custom component that renders an array of form fields:
there's no need to flatten this element. if you submit a form with this component, you'll get one row in webform_submitted_data for each field in the $element array. if for some reason you wanted a single row instead of multiple rows, you could flattening $values in the submit hook, like the file component does.
finally, let's say you have a component that is deeply nested. i don't have a great use case for this besides my need to provide a component with multiple fieldsets. it probably is an obscure use case, but i spent enough time debugging webform to figure out why it was throwing away my data, that i'd like to save someone else the time if i can :)
so now we have an array with 3 levels coming out of the render element. when you submit a form with this component, you have a data structure like (iirc) $form_state['values']['submitted'][$form_key]['deep_fieldset']['nested_field']. when _webform_client_form_submit_flatten() recurses through this array it confused, and you end up losing data.
for components like this, assuming you want to save each of the nested field values to the database (that's my use case), you have to flatten the array in the submit handler or set #parents for each nested field to e.g. array('submitted', 'form_key', 'nested_field') to avoid losing the data.
here's a reroll of the patch with the paragraph in question moved to _webform_component_submit() and lightly edited
Comment #4
quicksketchYes my examples may not have been the best either. I definitely understand where you're coming from. This patch looks good, I think it should apply to the D6 version directly, I'll put it in next time I'm working on Webform.
Comment #5
quicksketchCommitted to both 3.x branches.