Codex

Entwickler und Administratoren

Hat PmWiki irgend einen Weg, Seiten zu sperren ("edit locking"), sodass ein Autor, der eine Seite bearbeitet, exklusiven Zugriff auf die Seite hat?

PmWiki kennt kein "Edit-Locking" und es braucht das auch nicht. Wenn zwei oder mehr Autoren an einer gleichen Seite arbeiten, wird PmWiki entdecken, dass das passiert ist, und wird die Inhalte zusammenfügen zu einem einzigen Dokument. Es wird außerdem jeden Konflikte durch das Editieren kennzeichnen und dem Autor die Gelegenheit geben, die sich ergebende zusammengeführte Seite anzusehen, bevor er sie speichert.

Für diejenigen, die interessiert daran sein könnten, beschreibt der Rest der Seite Gründe, warum Seiten zu sperren schwierig ist und nicht wirklich in einem Wiki/Web-Kontext funktioniert.

Die normale Bedeutung von "Seite sperren" mit dem Bearbeiten einer Seite im Wiki ist, dass, wenn jemand eine Seite zu bearbeiten beginnt, andere Leute nicht die Erlaubnis haben, die Seite zu ändern (die Seite ist gesperrt) bis die originale Person ihre Änderungen beendet und den "Speichern"-Knopf anklickt, um die Änderungen zurück zum System abzuschicken.

Das Problem im Web ist, dass ein Autor möglicherweise nie den "Speichern"-Knopf anklickt und damit die Seite nie wieder freigibt. Es gibt viele Möglichkeiten, wie ein Autor das Bearbeiten der Seite abbrechen kann — Klick auf den "Zurück"-Pfeil des Browsers, Schließen des Browsers, Herunterfahren oder Versagen des Rechners oder des Netzes, etc. Aber bei allen diesen Möglichkeiten hat PmWiki keinen wirklichen Mechanismus, wie es von dem Abbruch erfahren kann, denn alle diese Vorkommnisse geschehen, ohne dass irgend eine Nachricht an den Webserver versandt wird. Wenn also ein Bearbeiten abgebrochen wird, bleibt die Seite auf dem Server für weiteres Bearbeiten gesperrt, auf ein "Speichern" wartend (das nie kommen wird), bevor eine Freigabe erfolgt.

Mit jedem Sperrschema muss es also ein Protokoll geben, das PmWiki erlaubt festzustellen, wann ein Bearbeiten abgebrochen wird, sodass die Sperrung sicher freigegeben werden kann. Einige Ideen dazu haben Folgendes eingeschlossen:

  1. Erlaube Sperrungen automatisch nach N Minuten wieder freigegeben zu werden. Die Wahl eines guten Wertes für N ist hier ziemlich knifflig — wir wollen ihn groß genug haben, dass die Zeitspanne, die ein Autor an einer Seite sitzen könnte, abgedeckt ist. 30 Minuten ist möglicherweise ein praktikables Minimum. Aber diese Annäherung enthält einige Pferdefüße — wenn jemand auf Bearbeiten klickt und gleich darauf den Zurück-Pfeil des Browsers anklickt oder den Browser schließt, ist die Seite für weitere N Minuten gesperrt. Durch Speichern von Cookies in des Autors Browser könnten wir es möglich machen, dass der Autor ein Bearbeiten anfordern kann und die Sperrung dabei umgeht. Aber das erfordert das Speichern von Cookies, was manche Leute nicht mögen, und die Seite ist für alle anderen Autoren trotzdem noch für weitere N Minuten gesperrt.
  2. Erlaube Autoren, sich über die Sperrung hinwegzusetzen. Wenn ein Autor bei einer gesperrten Seite auf Bearbeiten klickt, erhält er eine Nachricht, dass die Seite augenblicklich gesperrt ist und er aber die Möglichkeit hat, das Bearbeiten trotzdem fortzusetzen, obwohl die Seite gesperrt ist. Aber PM mag das nicht, weil es naive Autoren abschrecken oder sie verwirren könnte, und es könnte das falsche Signal aussenden, dass die Seite gesperrt ist für das Bearbeiten, obwohl das Bearbeiten durch jemanden anderen in Wirkllichkeit abgebrochen wurde.

An dem Obigen kann man sehen, warum Zusammenführen von gleichzeitig bearbeiteten Seiten eine überlegene Methode ist, mit den möglichen Konflikten beim Bearbeiten umzugehen: es vereinfacht das Behalten der Daten, das PmWiki durchführen muss und (im Einklang mit PmWiki-Philosophie #1) es ist freundlicher mit den Autoren.

Category: PmWiki Design


Übersetzung von PmWiki.PageLocking Originalseite auf PmWikiDe.PageLocking - Links de retorno
Zuletzt geändert:
PmWikiDe.PageLocking am 17 de junh
PmWiki.PageLocking am 10 de sete