hook_options_list() + XSS filtering

Additionally, this needs an additional helper module for tests, so there's some files moved and created.
I'll provide a cvs summary once this is RTBC.

Wow, forgot to run the tests one last time after a late refactor. That one should be better.

Stupid me. *That* one.

Should be there now.

LOL at 'devel' in setup().

Bump. #622614: Consider reducing the number of field types depends on this.

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

Rerolled. How can we get reviews on this ? ;-)

Easier tracking.

1) and 2) Well the patch just moves the existing list.test file as is in a new dir, but fair enough. Fixed.

3) Well, this code is just sample code to demonstrate the expected result format. Of course an actual implementation would most probably build the list out of the $field properties and settings. Updated the PHPdoc and actual sample a bit.

4) forehead slap

Additionally, removed options.module knowing about 'List' field types. list.module enables the widgets for its field types through hook_field_widget_info_alter(), like any other field type (taxonomy, noderef/userref in contrib, other unknown contrib field types)

Is this hook required to implement for option type fields?

More accurately: it needs to be implemented by field type modules that want to use 'option widgets' for their field types. Tried to make that clearer in the PHPdoc.

Can multiple modules respond?

Nope, in this approach only the module defining the field type. It might be seen as a limitation: *any* 3rd party code can theoretically use hook_field_widget_info_alter() to add optionwidgets to any field type, but only the field type module can implement hook_options_list() to specify the options to display.

If this is a blocker, we might change that by moving to a callback approach and adding an entry in option.module's hook_field_widget_info():
'option_callbacks' => array('field_type_1' => 'callback_1', field_type_2' => callback_2', ...)
When you add option widgets to a field type in hook_field_widget_info_alter(), you also update the 'options_callbacks' property accordingly.
This entry cannot be a 'setting', though, because we want the callback to be constant for a given field type, and not something you can customize when you setup a given $instance (like $instance['widget']['settings']['option_callbacks'] = 'mymodule_foo').
A custom, unofficial entry in option.module's hook_field_widget_info() should work, even though a bit edgy.

Feedback welcome, but I'll focus on #438570-61: Field API conversion leads to lots of expensive function calls for now.

Rerolled after the formatter API changes.

CVS instructions for the patch:

cvs rm modules/field/modules/list/list.test
cvs add modules/field/modules/list/tests/list.test
cvs add modules/field/modules/list/tests/list_test.module
cvs add modules/field/modules/list/tests/list_test.info
cvs add modules/field/modules/options/options.api.php

1) Right. Was just fixed in #658358: inconsistencies in field type tests 'Group', it should not be reintroduced here...
2) That part of the code is just moved around to a different directory. I think originally this was copied from options.test, which has 'card_1' and 'card_2' for 'cardinality 1' and '2'. No real meaning here, reworked the names.
3) Fixed.

Back to RTBC after tests come back green.

Bad reroll. That one should come out better.

Try again. In #20 I forgot to edit the patch for newly created files.

Green, but 16 passes in OptionsWidgetsTestCase is not enough, this should be 176.
+ ListFieldUI tests don't even run.
Sigh. Will try to investigate later today.

Let's try this one.

Better. Back to RTBC.