[development] Data API
adrian at bryght.com
Wed Sep 6 19:22:47 UTC 2006
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
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
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,
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
with subtle differences for
a) node definitions through fapi
e) node_import module
f) probably pubsub module. and several other places.
This is also about having consistent, well defined, validation rules
inputs, which are separate from the forms. So they can be re-used
This is also about providing context for many other systems, such as
to provide a modicum of safety when doing output (ie: knowing that a
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's also about providing the place for the much needed relationship
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...
More information about the development