[development] Data API

[Mark Fredrickson]

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