[development] Data API

[Mark Fredrickson]

> 3) Forms are not data. Forms are presentation of data, and input of user
> data before it's massaged. In many cases, that differs from our model
> considerably. Making Forms API into Data API means that we bolt
> ourselves to a 1-1 field/column sort of relationship, or commit to ugly
> hacks and workarounds. In the old days, the node edit form used
> $_POST['edit'] to create the node object directly -- cast to an object
> and go! :-) It's a good thing that we've moved away from it.

I'd like to pick at this point specifically. While I agree that
forcing developers into a 1:1 relationship between form elements and
db columns is bad, why not start with that as a default? Given a data
definition that is 1:1, Drupal could do the hard work of storing that
data, leaving the programmer to work on other things. If the
programmer needs something more complicated, he/she could certainly
register a "#callback' on the data element which did the appropriate
validation and storage.

Taking this one step farther, modules could register new data
definition elements, like the various field modules do right now for
CCK. If the '#type' is 'foo-bar-baz', we could look up the foo-bar-baz
symbol in some sort of vtable and call the appropriate function.
(Forget the days of "drupal is a framework", and welcome the "drupal
is a compiler" era).

Again, we already have a DDL, let's use it.

-M