CCK Widgets are FAPIized in 6.x

The 6.x port will make some significant changes to the widget API, so it would be good for CCK module authors to take a look at the changes and let us know if they need to propose any adjustments. I have been trying to look at some of the most widely used CCK widgets to see how they will be affected and am pretty sure that the new methods will be flexible enough to handle their needs, but it would be good to have other eyes looking at this, so here is a summary of what is changing:

The content module will now rely on FAPI to do most of the widget processing, since there is no longer any reason for the content module to create proprietary methods to do things that FAPI can do. There will be no more widget_invoke() calling hook_widget 'pre process' and 'post process', etc. Widgets will have to use #process, #value_callback, etc to do whatever processing they need. Widgets can use hook_elements to register elements that other modules can use. All widgets will add '#field' to their form elements to carry the $field array and make it available to later processes.

The content module will take over responsibility for multiple values processing. The content module will call hook_widget() as many times as necessary to create the full multiple valued field array, and each widget should respond by producing a single element.

The arguments for hook_widget() will change to make this work better. Instead of hook_widget($op, &$node, $field, &$items) it will be hook_widget(&$form, &$form_state, $field, $items, $delta). $form and $form_state will contain references to the entire form and form state for complex widgets that need that. $items will be the whole $items array, as it is now. $delta will be the pointer to the specific element to be constructed.

Handing off multiple values processing to the content module makes the widget code much simpler. No more loops and switches to handle differences between single and multiple valued fields. It will also make it possible for the content module to create a standard method for setting the number of multiple values that can be created and add other features related to multiple values, like javascript code to dynamically add more items. (Perhaps someone can rework the 'add more' javascript now in the link module for this purpose).

One of the most exciting outcomes of these changes is that the widget elements become completely agnostic about where they are being placed since they're not hard-coding $field['field_name'][$delta] (you won't see that anywhere in the new widget code). Elements can be combined or placed anywhere, so long as some kind of $field array can be passed to them to tell the element what title, description, and parameters to use. You can see some of the effect of this in the core modules where nodereference now uses the optionwidgets widget for a select widget and the text widget for the autocomplete. The content module will handle placing them on nodes, but the elimination of hard-coded field names means it should be possible to write custom code to place widgets anywhere, not just on nodes.

See http://drupal.org/node/157176 for more details.