I would humbly disagree that themes would be considered the view level, or that forms represent the model level in MVC. I think originally you could argue that the node api represented the model level, and that moving crud into the forms api represents a blurring of MVC and not a step towards that. That is the primary debate that's being waged here, whether we need separation of data manipulation from the controller. I personally would like to avoid creating a ddl in drupal. One of the things that make's drupal work is how agile the loosely coupled, loosely typed system is. The $forms arrays are collection of controls. I'd love to see them stay that way. right now forms posting and validation are accessed via simple array constructs. I'd like to see them stay that way. I agree that form_validate, form_submit, node_save, and node_delete functions (when used in crud) are really model work, especially the way they are used in 4.7. I think a lot of whats bothering some is that they're getting dependent on the forms api, and that dependency may cause inflexibility down the road. I agree that defining fieldsets, checkboxes, etc. have no place in the model portion of mvc. And having to set up those contructs provide extra cruft for programatic manipulation of data. (that's the forms dependency part creaping it's head). -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Mark Fredrickson Sent: Friday, September 01, 2006 7:33 AM To: development@drupal.org Subject: [development] Data API 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