Tags:
create new tag
view all tags
Refactored from Support.BrowserIssues. First statement cleaned up slightly as a result. -- RichardDonkin - 09 Feb 2002


To really fix the RefreshEditPage problem, there is only one solution: the logical one!

The same URL should point to the same data

Thus, for viewing, we should never refer to .../Main/WebHome, but to something like .../Main/WebHome?rev=1.34. However, this can be tricky (we must read rev number of all the links in a page) and the workaround of setting a short enough expire delay works well enough

And, for editing, a solution could be to generate a random (or the time of the day in seconds?) part to append to the URL for the link to click to edit. I patched this into the Dec 2000 version, and ity has worked flawlessly across all browsers I could test, and I redid my patch for the Sep 2001. I would strongly suggest that this patch becoms standard, see at the end of RefreshEditPage

-- ColasNahaboo - 23 Oct 2001

This looks very interesting - I'll give this a try when I get some time. It certainly looks like the right approach, and I would like to get rid of all these annoying cache issues, as they can put off new users.

-- RichardDonkin - 23 Oct 2001

What happens when someone follows their bookmark, or a link from another site .../Main/WebHome?rev=1.34 and the current revision is 1.65?

-- MattWilkie - 24 Oct 2001

Well, I wasn't clear enough: the trick is:

  • append to an URL some number that marks uniquely the contents of this page
  • but this number is there here only to help the browser decide its caching policy
  • TWiki should remove this number to process the page. On my submitted patch, I used something like |%2f%12%4b%57 as this was filtered out by the default $securityFilter, but we could use anything URL-legal, as long we filter it out before entering the TWiki main processing (e.g. filter out |.*$ and add numbers to the end of the URL in the form |4278482)
  • So in the above exemple the rev=1.34 is ignored by Twiki which will always fetch the latest version
  • A good strategy would be:
    • when vieving pages, have link to topics with date of file appended (as we already do a stat to check existence, should be fast enough)
    • edit button link to url with timestamp (or random number) appended
    • preview button link to url with timestamp (or random number) appended
This way we could let the caches work to their fullest. Note that the edit part is the really important one, the other are not error-inducing

-- ColasNahaboo - 24 Oct 2001

Of course, the other technique is to refactor it so that edit and preview are merged, so that when you preview a change there's a textbox on that same page, and you just hit "preview" again. Then you can set the new edit action to return a no-cache header. It won't cause problems, because you'll no longer have to go back. I think the interface would also be slightly nicer.

-- IanBicking - 27 Oct 2001

Refactoring is not a bad idea as a usability improvement (and has come up before, see SaveAndContinueWorkingFromPreview), but you might still run into caching problems if people use the Back button (as they almost always will), or hit Edit again a few minutes later. So I think the 'random URL suffix' idea is the way to go to fix this.

Having implemented ColasNahaboo's RefreshEditPage, I've found that it's possible to use this fix to resolve the BackFromPreviewLosesText problem, if aggressive browser caching is acceptable (a la Opera) - see the back from preview page for details. Since RefreshEditPage fixes one caching problem and helps with another, I think it should be part of the TWiki core.

-- RichardDonkin - 28 Oct 2001

I think the preview page should have a new textarea edit box like the edit page does, down at the bottom after the normal part of the preview page, so you can always continue editing, which is what I want to do 90% of the time. Or at least a button labeled "continue editing" that uses a hidden field to preload the edit textarea in the next page. In other words, never go back: be able to go forward either by committing or by continue editing. Sorry I haven't written this yet, but I think it's trivial.

-- StrickYak - 10 Feb 2002

That's a valid point, which I think has been suggested recently (search for slashdot, since SlashCode has a similar model, as does MeatBall). However, these user interface improvements won't in practice stop people from using Back, running into BackFromPreviewLosesText. Also, without the RefreshEditPage fix, you will run into the 'second edit loses text from first edit', no matter what the user interface, because the preview+edit page is just as cacheable as the normal Edit page.

User interface improvements are a completely separate matter to cache-related bug fixes for BackFromPreviewLosesText and RefreshEditPage - since there are now complete fixes for these issues, it's best to just implement those and then work out how we can improve the user interface as well (which does need doing!)

-- RichardDonkin - 11 Feb 2002

This topic, as well as the related BackFromPreviewLosesText, have become very long and they ramble a lot, so much so that I cannot make head or tail of either of them. If someone could write a short howto on this topic, one that is specific to 4.x versions of TWiki, that would probably be very useful to a number of people. I am thinking of something that would give short answers to questions like "How do I avoid revision-related confusion while accessing a TWiki using Opera (without having to click reload all the time?)"

-- RobertPersson - 03 Jul 2006

This topic here is outdated, I do not think it applies to TWiki 4.

-- PeterThoeny - 03 Jul 2006

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2006-07-03 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.