<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 27 Jan 2007, at 12:17 AM, Metzler, David 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 was wondering if the model code for the new forms API might be a good</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">place to start for syntax.<SPAN class="Apple-converted-space"> </SPAN>Wouldn't it be cool if the way we talked</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">about data for the model portion of a form would be the same as the way</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">we talked about data in the schema? Or does that seem silly?<SPAN class="Apple-converted-space"> </SPAN></FONT></P> </BLOCKQUOTE></DIV><BR><DIV>Might be useful, but the model portion is required for normal operation.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I don't know that we want to move the data structure to generate tables moved into the module</DIV><DIV>files at this point.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>It is definitely an idea for the future though, although the primary use of this would probably</DIV><DIV>be for a query builder, and I just don't see Drupal 6 including a query builder.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>There's a couple of major reasons that I still think functions are better than a single data structure however.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>1) if we end up nesting with entities (and stuff like indexes, and relationships), </DIV><DIV> we will end up with a very deeply nested array which could be very easy to mess up.</DIV><DIV>2) individual commands (ie: create table, create index), allow us to use the same code for the updates too.</DIV><DIV> if the schema is documented in a big array, we will be in a situation where we have to maintain the commands</DIV><DIV> as well for use in updates.</DIV><DIV> Or we try to analyze changes in the array structure to generate the commands automatically. This is a direction</DIV><DIV> I don't think we should move towards, as there be dragons there.</DIV><DIV>3) easier to debug. nuff said.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>--</DIV><DIV> Adrian</DIV></BODY></HTML>