Mark Fredrickson wrote:
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.
I would argue, instead, that we really should do a good object model of what objects Drupal is handling, and then at a base level map form elements to object attributes. Below that, the database layer translates the objects into tables. (No, users are not nodes. :-) ) We optimize object and SQL handling significantly and keep those darn hack module developers from mucking up the database and beautiful APIs. :-) (tongue very in cheek!) /me drinks some more Adrian Kool-Aid... ..chrisxj