Jeff Eaton wrote:
This is, in fact, how Drupal 6 works. :) Modules that need to shuffle their form data around before it can be considered a valid node object add a #submit handler to the node edit form. That code is called by both the preview and submit buttons when clicked, and results in a 'fully formed' node object when preview is clicked.
What happens if multiple modules need to shuffle the form date into $node? Is there a way to chain #submit events?
Basically, exactly what you outlined in your step-by-step process.
The only thing that wouldn't work is modules that add extra database information *after* the node is completely inserted into the DB, based on the nid, and then display it later. Frankly, I'm not too worried about that; creating loads of one-off dummy nodes just because someone typed a few lines and hit 'preview' strikes me as a very heavy solution for a problem that I'm not yet sure is a problem.
I think the idea of drafts has some merit but I'm unhappy with the idea of using the revision system for them. Drafts, if anything, should be an explicit workflow state; revisions are an optional construct that exists separately from workflow.
The problem with treating drafts as purely a workflow state is that drafts, ideally, should be able to co-exist with the published node. Having two coexistent versions of a node requires using revisions.
On Jun 8, 2007, at 12:11 PM, David Strauss wrote:
How it would work: 1. User submits node edit form. 2. The content type provider receives the submitted form values and applies them to $node. 3. The normal rendering happens on $node.