[development] CCK in Drupal 6

[Darrel O'Pry]

On Wed, 2007-02-07 at 14:28 -0600, Larry Garfield wrote:
> 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?

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.