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. 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. --Jeff On Jun 8, 2007, at 12:11 PM, David Strauss wrote:
The problem is that the current system is *almost* but not quite giving you what you will see when you save the node. It's difficult to give accurate previews. By running previews on the same system as revisions, previews will be 100% accurate and require no additional work to provide.
Another way we could structure previews accurately without the DB overhead of using revisions is to separate the node edit form submission from what changes in $node. Basically, submitting the form (for preview or saving) would call the function to apply the form submission to $node.
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.
Right now (and I may be mistaken for Drupal 6), elements on the node edit form get directly added to $node. When a preview is happening, the preview is built off this edit-form-modified $node, which often has a different data representation than $node really uses. So, the preview is put in the awkward position of interpreting the form and displaying the data.