[development] CCK in Drupal 6
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
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
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