[development] CCK in Drupal 6

Dries Buytaert dries.buytaert at gmail.com
Wed Feb 7 07:39:26 UTC 2007


Best e-mail of the week, Adrian.  I recommend people to bookmark it,  
and to add this to KarenS's issue in the patch queue.  Some below for  
comments. :-)

On 06 Feb 2007, at 13:47, 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).
>
> 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).
>
> 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.
>
> 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.
>
> 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.

So, if I understand correctly, you suggest that introducing more  
types (i.e. float, integer) and corresponding validation routines in  
core would be the first step.  This makes sense to me, and shouldn't  
be too hard.  Is anyone working on this -- or willing to work on this?


> 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.
>
> We use an incredible amount of complex logic to try and determine  
> the data model from the form array.
>
> Just about all the complexity in form_builder comes from this process.
>
> CCK does this the right way around, it creates a data model (by  
> defining the fields) and then converts the data model
> into a form / display. For consistency, we should then look at  
> making all forms use the same mechanism.

Yes!  I strongly believe this is the way forward.  It's not only key  
for the CCK, but for a bunch of other things as well, i.e. import- 
export, generating database schemas.  Once we have a proper data  
model, we can talk again about reworking the field handling of the  
profile module or creating a super-object that nodes are derived from.

I'd really love to make this one of the new killer features in Drupal  
6 -- it's ripple effect has huge potential and are much needed to  
advance Drupal.

Who intends to submit patches for that?  Are you going to work on  
this, Adrian?  I'm asking because I'd really like to see these kind  
of changes to go in early in the development process (say the next  
4-6 weeks).  Why?  Because I want to avoid a Drupal 4.7 scenario.  ;)

It would be great if we could focus on this NOW.  :-)

--
Dries Buytaert  ::  http://www.buytaert.net/


More information about the development mailing list