[development] Data API

[adrian rossouw]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20060906/523f2f92/attachment-0001.htm