[development] CCK in Drupal 6

Larry Garfield larry at garfieldtech.com
Wed Feb 7 20:28:04 UTC 2007

On Wed, 7 Feb 2007 22:11:11 +0200, adrian rossouw <adrian at 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?

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,

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

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

--Larry Garfield

More information about the development mailing list