Field Types: Make widget FAPI elements field agnostic.

Seems that I won this bug over here: http://groups.drupal.org/node/21270#comment-73506

A bit of clarification: "If the element needs anything from the field or instance, it should save it in the FAPI element during hook_field_widget."

"It" being the specific pieces of data needed, not simply the field or instance. Means that it requires a bit of thinking about the Form API interface widgets presents. For instance, number will need #number_type (integer/decimal/float), #precision, #scale, #decimal_point, #min and #max properties, with good defaults.

It does bring up the question of what to make of the #field_name, #bundle, #delta and #columns attributes that the standard fields adds to the sub elements they create. Assuming that Field API only cares about them (if at all) on the element it get from hook_field_widget, where it seems to stick them on, they should just be removed from the process functions. If that assumption holds, it would make things more easily understandable the first time one looks at a widget module.

*grunt* What happened with my comment?

Anyway, the last patch deals with number and text. Option is a bit more involved.

Now also with options.

One issue that needs attention: At first I used #options as the attribute for the options for the options_select, etc. elements, but that clashes with core, as it expects #options to be in the same format as for standard select/radios elements. In the case of options_* however, they're handled one level deeper. So I ended up renaming it to #options_options, which works. It doesn't taste good though.

Comments appreciated.

I don't think it's really related, but I could be missing something.

BTW, the change mentioned in this issue is only internal to each widget, and do not imply API change : the properties extracted from $field and $instance in widget's process and validate functions should be extracted in hook_field_widget() instead, and placed in # properties in the FAPI element, to be found by process and validate funcs.

Patch #18 was exactly in the right direction, except for the various if (!empty($instance['settings']['...'])) {, which are not needed (those properties are always populated)

Rerolled against HEAD.

I've also reimplemented some formatter functions that I seemed to have missed, which used field data, to use element data.

Needs testing.

Many thanks for sticking to this, Xen.dk. I'll try to review this time :-/ (when tests are green ?)

I've reverted the formatters, as I realized that they don't get anything like a form element.

Regarding tests:
Text Field
Test the creation of text fields.
40 passes, 44 fails, and 260 exceptions

The problem is, it's not simple failures. I was banging my head against:

GET http://localhost/drupal-7.x/?q=test-entity/add/test-bundle returned 0 (0 bytes).

Until I looked in Apaches log file and discovered that Apache segfaults 7 times during the Text Field test case.

Another machine:
Text Field
Test the creation of text fields.
61 passes, 18 fails, and 7 exceptions

And 5 segfaults.

I have no idea what's causing Apache to die, and it's not easy to debug Apache segfaults to begin with, nevermind the fact that it's doing it in requests internal to SimpleTest on an database environment that's torn down on each test.

First machine:
Linux scalpel 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
Second:
Linux saber 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux

If someone would try the attached patch and see what happens, I'm at a bit of a loss as to what I should do.

Straight reroll after #559486: Test bot doesn't always run all field attach tests and #559506: Field Widgets Need $langcode variable. Trying to reproduce the tests.

Hmm, I seem to be getting segfaults as well...
How does the patch behave on a manually tested text field on a node ?

Side note: patch still includes changes in theme_field_formatter_text_trimmed(). That probably accounts for a lot of the exceptions, at least.

Also:

-    '#attributes' => array('class' => array('number')),
+    '#attributes' => array('class' => 'number'),

is not right (also in text.module) - bad reroll after #326539: Convert 'class' attribute to use an array, not a string

Now that's interesting.. I cleaned up the above mentioned details and behold:

Text Field
Test the creation of text fields.
80 passes, 0 fails, and 0 exceptions

The 'widgets define reusable FAPI element types' approach is being dropped in core, as per #626354: Remove #process pattern from number field, so this task is this actually not needed anymore.

I owe Xen.dk a couple drinks :-/

*grunt*

Well, #626354 makes a lot more sense...

I should revisit the "fieldable field" thing I was playing with, to see if the changes to FieldAPI in the last 7 months have improved the possibility.

"fieldable field": bjaspan started some work around this back in DC Paris, as an implementation of 'combo fields', but I'm not sure what's the status of this.
See http://drupal.org/project/combofield

Hmm, looks like he's working somewhat along the lines I was thinking. I should look into that.

Thanks for the pointer.