[development] Use revisions to replace previews
jeff at viapositiva.net
Sat Jun 9 15:06:00 UTC 2007
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.
On Jun 8, 2007, at 12:11 PM, David Strauss wrote:
> The problem is that the current system is *almost* but not quite
> 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
> previews will be 100% accurate and require no additional work to
> Another way we could structure previews accurately without the DB
> overhead of using revisions is to separate the node edit form
> from what changes in $node. Basically, submitting the form (for
> or saving) would call the function to apply the form submission to
> 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,
> 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
More information about the development