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.