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/