Submitted by : 127.0.0.1 at: 2004-10-06T11:38:17+00:00 (13 years ago)
Name :
Category : Severity : Status :
Optional subject :  
Optional comment :

Hiya, Canonical is offering $100 to have ZWiki allow for previewing changes while editing. You can look at how moinmoin handles previewing while editing to see how this can work. To collect the bounty, I should to be able to upgrade ZWiki on a Plone site, and edit pages. When editing a page, I have the choice of either saving my changes or previewing my changes. On previewing, the changes are not saved to the database, the page is not put at the top of "recent changes" and subscribers are not notified. The preview page should show me how the page will look when rendered, and also allow me to change my text, before previewing again, cancelling, or saving. This bounty is available until 11 October 2004. (I discussed it on irc with Simon Michael on 27 September.)

--

Steve Alexander

(GoldOffer)

See also:

done --simon, Thu, 07 Oct 2004 22:56:40 -0700 reply

Steve, please see the edit forms at http://zwiki.org or http://plone.zwiki.org . If you pull from CodeRepos and restart you should get the same on your site. Comments welcome.

done --simon, Fri, 08 Oct 2004 00:00:47 -0700 reply

Fixed a bug with page type option.

back button --Tue, 19 Oct 2004 11:22:34 -0700 reply

Back button functionality, given a number of successive previews, may cause problems, and needs to be pinned down.

This is related to current and general back button and browser cache annoyances, which cause an older version of the page to be displayed in the editor than the current.

Note: The answer is NOT to force the user to click a button rather than use the Edit button. Preview alleviates teh "quick change" need, but going "back" to make that quick change upon render is natural, and as close as the side-buttons on many modern mice...

Note and File text box contents lost on preview --Tue, 19 Oct 2004 11:23:24 -0700 reply

Also haven't testing using HTML mode.

Notification of Edit Conflict? --Tue, 19 Oct 2004 11:26:18 -0700 reply

Should PREVIEW notify a user that they won't be able to save there changes due to an Edit conflict?

The only refernece I have to this is a PHPWiki? experience, which offered a useless (to me) Diff of the pages and offered text up to be copied for hand-merging the changes.

Note: This feauture is quite cool, and please don't be discouraged by the variety of feedback I'm putting on this page.

usability problem --simon, Fri, 22 Oct 2004 09:11:34 -0700 reply

I couldn't think of a solution for this, but I'm finding it hard to ignore: the changes to the edit form mean that save is no longer the default action. So if you just hit enter from the page name or log note fields, as I often do, it cancels instead of saving. Also I think this or another case causes the parenting to get confused so the page appears to be it's own parent.

usability problem --simon, Sat, 23 Oct 2004 20:53:28 -0700 reply

I've fixed this by simply reversing the order of buttons once again. It looks strange but usability wins.

back button --simon, Sat, 23 Oct 2004 21:00:06 -0700 reply

I believe browsers not showing current edit text when you hit back button is a separate issue (there is a page I think.)

Note and File text box contents lost on preview --simon, Sat, 23 Oct 2004 21:30:06 -0700 reply

Preview now preserves the change note.

It seems not possible to preserve the file upload selection, at least in firefox, so that will be lost if you preview.

Preview works fine with HTML/Epoz, except that it will not remember if you have selected the source mode checkbox.

back button + BAD DTML handling --Sun, 24 Oct 2004 18:59:24 -0700 reply

Right, there is another page for back button anomalies.

Related: I mostly deal with back button frustrations when composing DTML. Is the PREVIEW section surrounded by a try/catch? Doesn't look to be, preview crashes when inserting <dtml-var Moo> before preview. Would prefer a "Could not render" message, ideally with traceback, where the Preview section is.

file upload section --Sun, 24 Oct 2004 19:06:46 -0700 reply

> It seems not possible to preserve the file upload selection, at least in firefox, so that will be lost if you preview.

How evil is it to upload prior to Preview? (Then preview appropriately shows the added render line, with contents.)

back button + BAD DTML handling --Simon Michael, Sun, 24 Oct 2004 19:11:07 -0700 reply

I've found that hiding the real error, with it's traceback etc, leads to confusion. I think people saving bad dtml are generally trying to program and it's ok and in fact better to show them the original error.

back button + BAD DTML handling --DeanG, Mon, 25 Oct 2004 15:32:35 -0700 reply

I'd agree if the back button weren't so unreliable.. :-/

So you don't have the original error when you catch it in a whole-page wrapped try?

back button + BAD DTML handling --simon, Mon, 25 Oct 2004 15:34:50 -0700 reply

> I'd agree if the back button weren't so unreliable.. :-/

< splutter > what are you talking about deang.. please demonstrate this unreliability to me on irc some time.

back button + BAD DTML handling --Mon, 25 Oct 2004 22:18:35 -0700 reply

Will do. BackFromTheSandbox? . So far crap I recall from dtml frustration. But not havig it. :-) For now I'll attribute to old version scrappyness.

Still have problems of multiple previews with back button page expiration on a failed preview.

back button + BAD DTML handling --Mon, 25 Oct 2004 22:31:46 -0700 reply

Some of my cache problems could have been URL'ing between /editform and /manage in dmtl-hell, thus perhaps I can blame zope. Preview makes this much better, as a failed dtml-page edit doesn't save in Zope.

I'm still convinced Preview exceptions should be caught.

I just tried to remove the extra blank lines in the Rss2 page. Preview is not expected on this page, and of course will break. Try/catch/notify covers that. (Also got a clunk on trying to undo the /diff. It worked, but returned an index error...)

...back to a more pressing subject.

Page Rename and File text box contents lost --Mon, 25 Oct 2004 22:35:35 -0700 reply

You mentioned that the File name box couldn't be saved easily.

Just-do-it Solution: Uploaded it at Preview time. (Good for intranets, odd for internets?)

The page rename field is also lost on Preview. Is this equally hard to save? (and Preview?)

Page Rename and File text box contents lost --Simon Michael, Mon, 25 Oct 2004 23:09:34 -0700 reply

>Just-do-it Solution: Uploaded it at Preview time. (Good for intranets, odd for internets?) > > I don't like it because clicking preview is expected to be safe (no changes).

>The page rename field is also lost on Preview. Is this equally hard to save? (and Preview?) > > Thanks! I thought I took care of that. Fixed.

**paid, see
http://zwiki.org/932BountyForFullMoinMoinMarkup#msg20041027141807-0700@zwiki.org** --simon, Wed, 27 Oct 2004 14:19:38 -0700 reply

Status: open => closed

Previewing Changes --Thu, 12 May 2005 04:33:32 -0700 reply