[development] Data API

[Metzler, David]

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 at drupal.org
[mailto:development-bounces at drupal.org] On Behalf Of Mark Fredrickson
Sent: Friday, September 01, 2006 7:33 AM
To: development at 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