[development] CCK in Drupal 6

[Darrel O'Pry]

On Tue, 2007-02-06 at 14:47 +0200, adrian rossouw wrote:
> CCK exists of the following things for me :
> 
> 1. Field Types
> 2. widgets and formatters
> 3. Data model - consisting of the field types.
> 4. Query builder - crud functions. - generates query from data model.
> 5. Configuration interface - builds data model
> 
> I believe that we should integrate 1-3 into the forms api (and indeed  
> create the data api that way).

Yeah FAPI 3 !!

> All the field types that cck has, (ie: integers, floats, etc) have  
> validations already. Which is already
> much much stronger than what we have currently (using textfields for  
> everything. pfft).

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

In the current CCK model there are two layers of validation. The widgets
provide their own input validation that is naive to the requirements of
the data layer. The Data layer then validates what the widget produced
as final output. Are you envisioning a common validation or add
#validate callbacks to the data model as well?

> Form elements as we have them now, are essentially widgets as CCK has  
> them. Every field type has a default widget it uses. This is an extra (optional) property of  
> the form array.

Yes they are. CCK also provides a relation between widgets and the
fields they'll work with and settings per widgets. I would expect the
settings to the optional properties of the form array, and the default
widget to be meta data about widgets that the field module keeps track
of.

> So everywhere we have
> $form['title'] = array('#type' => 'textfield');
> we will then have :
> $form['title'] = array('#type' => 'text');
> 
> I don't believe we should make a differentiation for widgets /  
> formatters. They are just input/display widgets.
> All field types, have a default widget for editing, and for display.  
> These can be overridden in the fapi array.

That approach may solve the problem I'm having with formatters not
having settings, the way input widgets do currently. It may cause some
confusion for the people who have already been developing them, but
adding a flag and eliminating hook_formatter is good in my book... Hook
widget can go as well if the _value patch goes in. It should effectively
deprecate prepare.

However people will need to be careful about overriding widgets in for
CCK as different fields have different inputs and outputs. Theme
functions can just be tossed around merrily.

> I see that as a first phase, which would bring all the field type /  
> widget code into core.. and all forms will re-use the same
> code. Including profiles.



> Second phase : data model.
> ---
> As I specified in my data model presentation at the last DrupalCon,  
> we have a data model currently, it's
> just hidden in the form array structure.

I need to go re-examine your presentation