[development] Data API

Chris Johnson chris at tinpixel.com
Sat Sep 9 03:34:30 UTC 2006

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...


More information about the development mailing list