Widgets vs FAPI

CCK in Core

From development list - Adrian Rossouw and 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.

On 07 Feb 2007, at 8:56 PM, Darrel O'Pry wrote:

>

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

elements correct?

There are definitely 2 steps involved here.

widgets do processing on the input, to change it into the right data type.
(this is how i felt checkboxes/ select lists should have been handled, not
by being hardcoded in form_builder) fields validate the data that they
have been given, whether by code or by the widgets.

I don't believe we should include the validate functions for the field types
/ widgets into the form structure thought, because if we do it right,. every
single field will have validation rules, and all that information will not often
be modified (fields can still have additional validation rules of course).

We don't want to bloat the data structure unnecessarily.