On 06 Sep 2006, at 5:24 PM, Mark Fredrickson wrote:

I'd like to pick at this point specifically. While I agree that

forcing developers into a 1:1 relationship between form elements and

db columns is bad, why not start with that as a default? Given a data

definition that is 1:1, Drupal could do the hard work of storing that

data, leaving the programmer to work on other things. If the

programmer needs something more complicated, he/she could certainly

register a "#callback' on the data element which did the appropriate

validation and storage.


I agree with mark on this, the default case , which in 99.999% of the time is 
more than adequate, for both input AND output (forms and displays), can 
very very very easily be codified and not even be a concern for the developer.

Using the 'fapi' structure of sensible defaults that can be overridden, you could
really make it be anything.

Also, 99% of the time you only need the aggregate fields on output, not input.
so it would be much much cleaner to create a widget (theme function) that displays multiple
fields. Like for instance a graph that can display multiple points associated associated with a node.
It's one view of multiple data fields. 

Also, we use data models for a hell of a lot of things, We have data models re-implemented
with subtle differences for 
a) node definitions through fapi 
b) cck 
c) importexportapi
d) views
e) node_import module
f) probably pubsub module. and several other places.


This is also about having consistent, well defined, validation rules for all
inputs, which are separate from the forms. So they can be re-used more cleanly.

This is also about providing context for many other systems, such as the filters, 
to provide a modicum of safety when doing output (ie: knowing that a 'title' field
will need to be check_plain'ed, and a content field could be html and might have to
have a filter selector).

It's also about creating far far cleaner abstraction for things like file handling, so you can
just add a file field to any 'model', and the CRUD of the file 'model' knows how to save and handle
it properly.

It's also about providing the place for the much needed relationship API.

it's also about getting rid of the distinction between userapi and nodeapi, and instead provide
a sensible place for all objects to be extended (ie: anythingapi).

it's also about improving granular caching of objects, and even markup. With realistic 
methods for rebuilding cached objects when needed (this will lead to big performance benefits)

There are at least a dozen MAJOR concerns this will allow us to cleanly and consistently resolve,
and many dozens more new features we will be able to implement because of a system like this.

Being against an API like this because other systems have implemented something similar before
(really, what kind of a reason is that?), is incredibly incredibly short sighted. The simple fact that
other people have implemented it before should be a benefit , because we have the ability
to learn from their mistakes. 

I'll be discussing this all at DrupalCamp in Brussels in 2 weeks time, and I will be making my presentation
available online too.

In the mean time, if anyone would like to discuss this with me, I will be available on skype username: vertice123

If you've had experience implementing a similar system, or working with systems like RoR / CakePHP or anything
similar , or have some major concerns with the idea, I would like to speak to you. I am especially interested in
any forms you feel will be impossible with a system like this.