Wiki Home

Wiki Lock Pages


Namespace: Wiki

Steve I end up doing the same create/save/edit/save sequence a couple of times woud a "preview" button be easy to impliment it might be able to save a few records in the table at your end. David Frankenbach
Steve, If I select Edit on a page and then change my mind and just hit the Back button without making an edit do I hold the 5 minute edit notice on the topic for someone else? Perhaps a Cancel button could be used to release the "lock". David Frankenbach
Problem: I find myself doing this: 1 edit a page, 2 save, 3 look over the new text, 4 notice something needs to be fixed, 5 hit my browsers back, 6 edit the page, 7 hit save. This is great, as long as no one else edits and saves between 2 and 7, because when I hit 7 save, it will wipe their changes. -- ?CFK
This won't change anytime soon. The current notification system is fine. There is no way to reliably lock a topic. They try in the German fox wiki (http://www.foxuser.net) and it's unbearable, unusable, and totally unnecessary. There are 5,000+ topic wikis out there with no locking or notification whatsoever and they work just fine. What's to stop you from hitting your back button five houirs hence? It's just never going to be solvable without seriously interrupting the flow of using the wiki. -- Steven Black
Also, another thing I think I have done: 1 edit, 2 save, 3 wonder if someone else has changed the page, 4 hit reload which causes ie5 to display: "The page cannot be refreshed with out resending the information. Click retry to send this information again, or click cancel to return to the page you were trying to view." Hitting "Retry" does just what it said it would: Send it again, "it" being my save, right over the top of the edit I was trying to view. -- CFK (trouble maker!)
That's the way browsers work. You are trying to refresh a POST versus a GET. The only way that is allowed is to re-post the same form variables. If you just want to refresh the topic, either go out to Recent Changes and click back in, or edit the URL by changing the case (upper/lower) of one of the letters (your browser sees this as a new URL and performs a GET, which is what you want). -- Randy Pearson
Steve: Here is another idea that is far less likely to lose anyone's fine efforts. (1) Keep a timestamp in the table. (2) Send the timestamp with the FORM in the edit page as a hidden form variable (TYPE=HIDDEN). (3) In the code that processes a form submit, lock the record and compare timestamps. If they don't match, someone else has updated the record in the interim. (4) Reject the change and tell the user why. The advantage to this is they can use their BACK button to fetch their own changes on the clipboard, and then re-edit the page and paste the new changes in.

I've implemented this in some Web Connection applications with success. You could even combine the two approaches: Use the approach above, but also employ the method I suggested below to display a warning that someone else is likely editing the same page. -- Randy Pearson
That's another really good idea, Randy. Expect to see this real soon now. -- Steven Black
Here is a simple approach that could help the Wiki in cases where 2 people try to edit a page at one time.

One is to include a "check out" datetime field in the table (possibly even a field for who). You fill this in when someone hits Edit. Now you pick some arbitrary time constant, say 10 minutes, and if anyone else hits edit during that time, you display a warning like "Steven Black started editing that page 6 minutes ago. Maybe you want to wait a moment for him to complete his changes." Then, of course, clear the timestamp when the change is submitted. It's not robust, but it is easy to do and for this kind of application, seems adequate. -- Randy Pearson
That's a really good idea, Randy. I like it. -- Steven Black
And if I'm composing a Wiki and get called away (as just happended) I lose my edit? I'd say implement the scheme with no time out and just the notification and let the community police dangling locks. A more robust implementation would involve writing a cookie each time a wiki is edited that contains a timestamp. This could be compared with the wiki on save and if a conflict occurs the user saving the wiki would have to force the save. - jMM
Category Wiki
( Topic last updated: 1999.10.09 04:12:22 PM )