Move $form['#field'] meta information into $form_state

Minor FAPI bug I found out along the way: #641544: FAPI #type 'container' ids generated twice

+ forgot to set to CNR

Argh @ translation tests.

Well, for now, reroll after #619230: Update 'default field value' UI code for D7 Field API and fix for the 'Field attach' failure.

Attached patch should fix the TF failures.

OK, reducing the scope a little.

Attached patch removes the #parents part - automatic extraction of #parents at after_build time, + using the 'parents' in field_default_extract_form_values().
I still think it's a good approach, but:
- this can be debated in #627730: Make field forms resilient to form_alter() structure changes,
- there are other places in core that currently rely on a hardcoded location in $form_state['values'][$field_name][$langcode]: file_field_widget(), locale_field_node_form_update_field_language(), and changing those would take the patch too far off,
- I don't want this to stop the $form['#fields'] -> $form_state['storage']['field_info'] change from getting in.

So, updated patch does as described in the OP without item 4 and the 'parents' component in $form_state['storage']['field_info'].

+ Marking as critical, since with the current code, a contrib module form_altering the structure of the $form without updating $form['#fields']'s 'form_path' accordingly causes field-level validation errors not to be reported on the form.

Rerolled after #639428: Remove #process pattern from text field (no more changes needed in text.module)

Rerolled after #635094: Unify "language neutral" language codes

easier tracking

Rerolled.

Rerolled.

Patch summary, updated from the OP:

Field API currently stores meta information about the fields being edited in $form['#fields']. For each field, $form['#fields'][$field_name] has:
- 'field', 'instance': the full $field and $instance definitions.
This is the information that all widget processing callbacks (FAPI process, validate, value callbacks) are supposed to use if they need some info about the field or instance - NOT field_info_field() or field_info_instance(). This lets us build form elements for 'variants' of a field, different from the officially stored definition - for instance in views exposed filters, or in Field UI admin screens.
- 'form_path': path to the field form element within the $form structure (what Form API actually calls #array_parents).
This is used in the AJAX 'add more' handler, and in the assignment of field validation errors down to actual form elements.

This information bloats $form and makes a print_r($form) tedious. This belongs in $form_state, but couldn't live there before $form_state persistence and auto-rebuild behavior got cleaned.
Also, not all FAPI callbacks receive $form (some receive an $element), but all receive $form_state.

1. removes $form['#fields'] and introduces $form_state['storage']['field_info'] - for each field:

      $form_state['storage']['field_info'][$field_name][$language] = array(
        'field' => $field definition,
        'instance' => $instance definition,
        'array_parents' => (previously 'form_path') FAPI #array_parents : path to the field elements in $form
        'errors' => the array of field-level errors reported by hook_field_validate()
      );

2. fixes widgets that were incorrectly relying on field_info_[field|instance]() instead of $form['#fields'], and also clearly documents that practice in hook_field_widget() (actually that's still a @todo in this version of the patch)

3. makes field_add_more_js() and field_default_form_errors() use the $form_state 'array_parents' info (prevsiously used the info from $form['#fields']).

4. automatically populates 'array_parents' at #after_build time.

5. adds $form and $form_state args to hook_field_widget_error(). That's a widget hook, those arguments belong here, even if most implementations probably won't need them (current ones in core do not). API addition rather that API change, since nothing breaks if a given hook overlooks those additional args.

'crtical' because with the current code, a contrib module form_altering the structure of the $form without updating $form['#fields']'s 'form_path' accordingly causes field-level validation errors not to be reported on the form and thus bypassed.

I agree with the change.

All in all, it's probably still sun who can RTBC ;-).

Ah true, I left dome docs @todos pending for an initial approval of the approach :-/
Will try to add those asap.

Fixed the doc @todos.

Patch summary is in #15.

+++ modules/field_ui/field_ui.admin.inc 15 Jan 2010 20:31:48 -0000
@@ -1196,6 +1196,7 @@
+    '#parents' => array(),

That's for the widget element used as 'default value' input in the field settings form. That change goes along with those in the _validate and _submit form handlers:

+++ modules/field_ui/field_ui.admin.inc	15 Jan 2010 20:31:48 -0000
@@ -1217,25 +1214,22 @@
-    // Extract field values.
-    $items = array();
-    $form_state_copy = array('values' => $instance['default_value_widget']);
-    field_default_extract_form_values(NULL, NULL, $field, $instance, LANGUAGE_NONE, $items, $form, $form_state_copy);
(...)
+  $items = array();
+  field_default_extract_form_values(NULL, NULL, $field, $instance, LANGUAGE_NONE, $items, $form, $form_state);

It's a fine change, except I guess it doesn't really belong in this patch now (the initial patch in the thread ventured into 'parents' and $form_state ['values'] land).

I removed those hunks from the patch.

The docs state that the values are added by reference, but this doesn't seem to be the case?

Hm, the 'array_parents' and 'errors' entries are initialized as empty arrays by ref in f_attach_form() / f_default_form(). The doc also says that they are actually populated respectively at form build time and form validation time.

Other remarks fixed.

Powered by Dreditor.

Spin off for the '#parents' => array() hunks in field_ui 'edit default value' : #686226: Nicer code in 'default value' input handling

Rerolled - was a hunk for a trailing whitespace fix that got committed meanwhile.

Not sure why this was reopened ?