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.