[development] Data API
Jeff Eaton
jeff at viapositiva.net
Sun Sep 3 17:38:57 UTC 2006
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
More information about the development
mailing list