[development] Data API

[Jeff Eaton]

Frando (Franz Heinzmann) wrote:
> I think by extending the FormAPI concept to a Data API we can ease and 
> simplify drupal module development quite a lot. By adding some more 
> "magic", as some scaffolding here and there or considering the fAPI 
> arrays not as description of forms but as data models, lots of things 
> (as different methods of interacting with a website, e.g. XML-RPC or 
> import/export modules) would be far easier to realize.
>
> regards,
> frando
Frando,

In a couple of adrian's messages, he's noted that the Forms API's big 
problem is that it is blurred with a data management API. chx and I have 
spent a lot of time up to our necks in form.inc during the 5.0 
development cycle, and I can offer the following observations.

1) We're using structured arrays to store LOTS of information these 
days. I think that's a good thing, not because arrays are better than 
anything else but because we are settling on a standard representation 
for complex information (including parent/child information). Array 
trees, with a #key_suffix to distinguish flags and properties, works.

2) Rendering HTML with that structure works, and works pretty well. 
drupal_render() can be used for an awful lot of things now, and I hope 
we take advantage of it, completely apart from forms.

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.

4) As per adrian's suggestions, defining our data model is a task that 
our structured arrays could be great at. A data model can be used to 
auto-generate an edit form definition, which can be customized by a 
developer at will. It's worth noting that the programmatic form 
submission function that's in 5.0 is 'drupal_execute()', not 
'drupal_submit_form()'... I'm hoping that as we move towards a data 
model that can be used in more generic fashion.

To recap, I think the future lies in: Render API splatting stuff into 
HTML, Forms API managing roundtrip/workflow issues with HTML forms, and 
Data API managing data definitions and CRUD. The more time I spend 
working with forms, the more I drink the adrian kool-aid. ;)

--Jeff