After the previous round of talks on the form api, I have a proposal for future Drupal development: let us rename the form API to the data API and start to look at it as the central method of implementing a full MVC in Drupal. First, some observations: HTML forms are simply a method of getting data from users, nodes are collections of defined data, nodes are increasingly represented as "forms" - however, coupling our data to an XHTML representation blurs the line between model and view. The general benefits and costs of an MVC design pattern are outside the scope of this email, but feel free to criticize my position if you don't like MVCs. I will say, MVC isn't the only design pattern, but it's a good one if you don't have a reason to choose something else. Let me map the model, view, and controller to current and future Drupal constructs: 1. Model: I think most people would say that the current model is just the db schema. I say that the model should be the schema AND the data definition (currently in the shape of a form definition). In fact, I might argue that schemas should be phased out for a database abstracted system. Imagine if you could just define a simple data structure in the form: $mydata = array( '#type' => number, '#name' => 'My Number', '#default_value' => 1234, ); etc... While I agree that we having a drupal specific DDL is bad, the reality is that we already do have one: the current formAPI. Accepting that fact and writing tools to turn $mydata into a db schema will only help development, not raise the barrier. 2. Controller: These are the _submit and _validate functions right now. I know there is work going on to more flexibly work with these items (eg. I owe a patch to allow binding of buttons to functions). I think the controller layer probably needs the most work. The recent nodeapi vs. formAPI (call it Data API now!) illustrates this fact. 3. Views: Arguably, these are the theme_* functions; however, this is where the coupling of data to XHMTL forms I mentioned earlier comes in. Take for example '#type' => 'checkbox'. This definition makes me cry every time. Multiselects and checkboxes should be collapsed into one type: multi. Radios and drop downs should be collapsed into one type: single. Text boxes and text fields should just be one type, varied on size (and perhaps something else to allow filtering). If we move these functions into the theme layer, forms API will stop being just about forms and wills start being about data. Good. So, what are the benefits of this system? First, I think changing the semantics of the name will allieviate some confusion regarding the role of the Data API. The recent nodeapi discussions have shown that there is confusion over where and when data should be manipulated. I think it gives us CCK like features right out of the box. Since most of the data api will be used for defining nodes, it seems natural to me that users could define forms online and Drupal would turn them into types on the fly. This email is getting long as it is, so I'll end it here. Of course, discussion is welcome. Cheers, -M