<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On 31 May 2007, at 9:02 PM, Jeff Eaton wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">For the idea to be a reality, CCK needs actual honest-to-goodness granular CRUD functions underneath the surface, and any forms it uses for configuration purposes need to call those CRUD functions instead of overloading the validate and submit handlers. We also need to hash out what happens when Field plugins change their settings definitions, etc, what happens when the in-module definition for a content type changes, etc. Right now it only works for the creation of new node types from scratch.</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> </BLOCKQUOTE></DIV>Yeah. updating could get flakey. Since it's two forms instead of one. Perhaps making them multipage forms instead would simplify what happens.<DIV>Only one form to submit for creating and editing field definitions.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I personally believe that any time a form isn't re-usable via drupal_execute, that's a critical bug that needs to get fixed.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>You'd also have to keep track of which fields have been removed, although that's a pretty simple since fields aren't multiple levels deep.</DIV><DIV><DIV><DIV><DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV></DIV></DIV></DIV></DIV></BODY></HTML>