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