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