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