[development] Use revisions to replace previews

[David Strauss]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.drupal.org/pipermail/development/attachments/20070609/be8d0a46/attachment.pgp