
<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>On 31 Aug 2006, at 9:00 PM, Andrew Lee wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; ">Precisely, by keeping crud at the data object level, aki nodeapi, we have a better chance of decoupling the form level. Is there any reason that a module should not be able to implement different form interfaces to the same node object? Most applications do this in one way or the other.<SPAN class="Apple-converted-space"> </SPAN><BR></SPAN></BLOCKQUOTE></DIV><BR><DIV>The issue is that FAPI (it really shouldn't be called that), muddles the data structures for the view and model components of the MVC structure.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>You _do_ have a data model in the form, but we need a function like form_builder to extract it.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I will be discussing at DrupalCon how to untangle these two concerns, and how it ties into CRUD. </DIV><DIV>(every 'type' with a model, automatically gets a form 'scaffolding' it.)</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>