[development] Use revisions to replace previews

[David Strauss]

Morbus Iff wrote:
>> Not only that, but I have visions of a database full of trivial or even
>> identical node revisions. For example, what if the user changes only the
>> taxonomy selections and then previews the node? All those DB queries and
>> extra data in the table, for nothing. Or they change a bit of HTML
>> formatting
>> and preview, trying several times to get it just right. The user may have
>> only worked for a couple of minutes, so what's the value in preserving
>> all those
> 
> This is pretty much the way I work - I could easily spend 30 previews
> before I finish what I consider my first draft of a node. I would hate
> to waste 30 revisions (and the overhead) for stuff like that.
> 
> Likewise, I tend to think this is a semantic breakdown - when I
> "preview" something, I am doing so because I want to see what WILL
> happen IF I saved/the data. The revised change breaks this meaning,
> making it more a "save and re-edit" button, not "preview".

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.

-------------- 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/20070608/ff83e9d6/attachment.pgp