
<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 06 Sep 2006, at 5:24 PM, Mark Fredrickson wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">I'd like to pick at this point specifically. While I agree that</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">forcing developers into a 1:1 relationship between form elements and</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">db columns is bad, why not start with that as a default? Given a data</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">definition that is 1:1, Drupal could do the hard work of storing that</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">data, leaving the programmer to work on other things. If the</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">programmer needs something more complicated, he/she could certainly</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">register a "#callback' on the data element which did the appropriate</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">validation and storage.</FONT></P> </BLOCKQUOTE></DIV><BR><DIV>I agree with mark on this, the default case , which in 99.999% of the time is </DIV><DIV>more than adequate, for both input AND output (forms and displays), can </DIV><DIV>very very very easily be codified and not even be a concern for the developer.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Using the 'fapi' structure of sensible defaults that can be overridden, you could</DIV><DIV>really make it be anything.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Also, 99% of the time you only need the aggregate fields on output, not input.</DIV><DIV>so it would be much much cleaner to create a widget (theme function) that displays multiple</DIV><DIV>fields. Like for instance a graph that can display multiple points associated associated with a node.</DIV><DIV>It's one view of multiple data fields. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Also, we use data models for a hell of a lot of things, We have data models re-implemented</DIV><DIV>with subtle differences for </DIV><DIV>a) node definitions through fapi </DIV><DIV>b) cck </DIV><DIV>c) importexportapi</DIV><DIV>d) views</DIV><DIV>e) node_import module</DIV><DIV>f) probably pubsub module. and several other places.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is also about having consistent, well defined, validation rules for all</DIV><DIV>inputs, which are separate from the forms. So they can be re-used more cleanly.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>This is also about providing context for many other systems, such as the filters, </DIV><DIV>to provide a modicum of safety when doing output (ie: knowing that a 'title' field</DIV><DIV>will need to be check_plain'ed, and a content field could be html and might have to</DIV><DIV>have a filter selector).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It's also about creating far far cleaner abstraction for things like file handling, so you can</DIV><DIV>just add a file field to any 'model', and the CRUD of the file 'model' knows how to save and handle</DIV><DIV>it properly.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It's also about providing the place for the much needed relationship API.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>it's also about getting rid of the distinction between userapi and nodeapi, and instead provide</DIV><DIV>a sensible place for all objects to be extended (ie: anythingapi).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>it's also about improving granular caching of objects, and even markup. With realistic </DIV><DIV>methods for rebuilding cached objects when needed (this will lead to big performance benefits)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There are at least a dozen MAJOR concerns this will allow us to cleanly and consistently resolve,</DIV><DIV>and many dozens more new features we will be able to implement because of a system like this.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Being against an API like this because other systems have implemented something similar before</DIV><DIV>(really, what kind of a reason is that?), is incredibly incredibly short sighted. The simple fact that</DIV><DIV>other people have implemented it before should be a benefit , because we have the ability</DIV><DIV>to learn from their mistakes. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'll be discussing this all at DrupalCamp in Brussels in 2 weeks time, and I will be making my presentation</DIV><DIV>available online too.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In the mean time, if anyone would like to discuss this with me, I will be available on skype username: vertice123</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If you've had experience implementing a similar system, or working with systems like RoR / CakePHP or anything</DIV><DIV>similar , or have some major concerns with the idea, I would like to speak to you. I am especially interested in</DIV><DIV>any forms you feel will be impossible with a system like this.</DIV></BODY></HTML>