On Wed, 2007-02-07 at 14:28 -0600, Larry Garfield wrote:

On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian@bryght.com> wrote:

...

On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote:

...

This can be overcome with a few simple #validate functions on form elements correct?

There are definitely 2 steps involved here.

widgets do processing on the input, to change it into the right data type. (this is how i felt checkboxes/ select lists should have been handled, not by being hardcoded in form_builder) fields validate the data that they have been given, whether by code or by the widgets.

I don't believe we should include the #validate functions for the field types / widgets into the form structure thought, because if we do it right,. every single field will have validation rules, and all that information will not often be modified (fields can still have additional validation rules of course).

We don't want to bloat the data structure unnecessarily.

Potentially naive question from someone who has not used FAPI to its fullest extent yet: What does hook_widget offer that hook_elements does not? Would it be feasible to simply beef up hook_elements to fill in any missing functionality that hook_widgets has that it doesn't, then deprecate hook_widget?

The widget callbacks in CCK, hook_widget_info, hook_widget_settings, and hook_widget provide a few things above and beyond form elements. 1) hook_widget_info, A way to specify which widgets work with which fields. 2) hook_widget_settings, provides a form and setting so users can configure widgets through the browser when creating field instances. 3) hook_widget, the only unique addition that can't be handled through the current FormAPI is the prepare op.

That would give us the bonus of CCK-added fields and form_alter value-add fields both being able to support "rich fields". Instead of a CCK field called "node reference", you'd have a FAPI element called node_reference:

$form['other_node'] = array( '#type' => 'node_reference', '#default_value' => $node->other_node ? $node->other_node : 0, '#required' => TRUE, );

I think we're kind of headin in this direction but you would call $form['other_node'] = drupal_field('nodereference');

And then you could do the same with arbitrarily complex elements/fields which can then be value-added or CCK-added via the admin.

The problem is these kinds of constructs are currently only valid on nodes, since CCK in its present form is about decorating nodes with custom fields. I've been playing with the idea of field instances and their values as their own data silos, much like Ber's idea of microcontent I think, and similar normalized lookup or attribute tables in databases. I don't think this is within the scope of getting CCK into core. I think we should avoid new features at all costs, until we get the integration done right for our existing feature set. Then start planning how to expand on it.

Or am I completely misunderstanding hook_elements entirely (which is entirely possible)?

hook_elements basically defines a set of defaults for a '#type'. Its nice to have simple dumb elements. I'm not sure you need a widget all the time and widgets use elements themselves. With #process they're nicely nestable.