[Home] 
Tu To Ri / Zugriffskontrolle
Home
TuToRi/

Neues
TestSeite
Forum

Suchen
Teilnehmer
Communities
Ordner
Index
Hilfe

Einstellungen

Ändern

   Die Zugrifskontrolle soll das Problem beheben, das auftritt, wenn zwei User gleichzeitig den gleichen Artikel überarbeiten. In dem Fall löscht einer der beiden die Überarbeitung des anderen, ohne dass er dies mitbekommt. Das ist aber dank der Abos nur halb so schlimm. In der Regel abonniert man auch den Artikel, den man überarbeitet hat. Also wird man auch von dem Überschreiben in Kenntnis gesetzt und kann seine Änderung wiederholen. Der eigentliche Grund, warum ich auf das Feature verzichte, ist die Schnittstelle, welche für Programme wie z.B. einen extra Browser oder Bots gedacht ist. Änderungen an Artikeln über diese Schnittstelle können nicht das Zugriffsrecht für sich in Anspruch nehmen. Das würde die Schnittstelle zu kompliziert machen. Und eine Zugriffskontrolle, welche sich nur auf User bezieht, die einen normalen Browser benutzen, wäre nur sehr halbherzig und sinnlos. Man würde dadurch eine Sicherheit der Eingabe vortäuschen, welche nicht gegeben ist.

Ich glaube, dass diese Design-Entscheidung falsch ist. Es ist nicht gut, etwas deswegen nicht zu machen, weil der technische Aufwand oder der Entwicklungsaufwand dafür hoch ist. Es nützt dem Benutzer wenig, wenn er erfährt, dass sein Beitrag kollidiert ist und überschrieben wurde, wenn er den Text nicht separat gesichert hat - und wer tut das schon routinemäßig. Ein Benutzer, der auf solche Art viel Arbeit verliert und wiederholen muss, ist schon fast ein verlorener Benutzer, der dem System - das für ihn unzuverlässig war - den Rücken kehrt. -- HelmutLeitner 22. September 2004 18:36 CET

Der erhöhte Aufwand, welcher bei mir liegt, stört mich nicht. Das Problem ist, dass ich den Nutzern der Schnittstelle beibringen soll, ihre Programme dann dementsprechend zu gestalten. 
  1) Zugriff auf Artikel reservieren
  2) Aktuelle Version auslesen
  3) Inhalt verarbeiten
  4) Neue Version auf den Server laden
  5) Zugriff wieder freigeben
Keiner garantiert mir, dass sie sich auch daran halten. Sie können immer bei einem Zugriff die Daten auslesen und bei einem anderen ihre Version auf den Server laden. Zwischen den beiden Zugriffen kann sich dann viel tun. Egal was ich mache, ich kann die Leute nicht dazu zwingen, ihre Programme so zu schreiben, dass das Lesen und Schreiben im selben Zugriff stattfindet. Besonders, weil ich den Zugriff nach einer bestimten Zeit wieder freigeben muss, damit ein Artikel nicht für immer blokiert ist. Sollte diese Zeit abgelaufen sein, wird jeder Programmierer das Programm so schreiben, dass es ein neuen Zugriff anfordert und dann die alten Daten auf den Server schiebt. Kaum ein Programmierer wird sich da die Mühe machen, noch eine Überprüfungsrotine zu schreiben. Da siegt auf jedenfall die menschliche Faulheit. Die einzige Möglichkeit, das sauber hinzubekommen, ist, wenn nur ich die Programme schreibe. Aber das würde den Sinn einer Schnittstelle total zerstören.
Ausserdem verschwindet die überschriebene Version nicht, sie ist im Archiv ja noch gespeichert. Da kann man sich dann die entsprechende Textstelle heraus kopieren und neu einfügen. -- SebastianKühn 22. September 2004 19:07 CET

SK-Genius: mitlerweile hab ich eine einfache möglichkeit gefunden doch noch ne "zugriffskontrolle" einzubaun. dies ermöglicht sogar das 2 user in einem artikel zeitgleich zwei unterschiedliche kapitel bearbeiten können. die umsetzung ist so simpel wie genial. wenn man ein kapitel eines artikels bearbeiten möchte, so wird der inhalt des kapitels in das editorfenster kopiert. beim versenden des überarbeiteten kapitels wird neben der neuen version auch die alte mit versendet. darauf hin wird geprüft ob die mitgesendete alte version noch die gleiche ist, wie auf dem server. wenn dies zutrifft wird das alte kapitel überschrieben (nur das kapitel, und nicht der ganze artikel). sollte es abweichungen geben, so wird man auf diese hingewiesen (in welcher form weiss ich noch nicht, ich werde diese funktion auch erst im nachhinein einbauen).

sigi: endlich mal wieder eine durchgehende klein·schreibung . ist doch viel einfacher . und wer auf die gewohnten gross·buchstaben beim lesen nicht verzichten will, kann seinem browser ja beibringen, ihm den text in der alten syntax zu servieren . eine einheitliche daten·verwaltung sollte auf jeden fall in absoluter klein·schreibung stattfinden .

SK-Genius: etwas sehr weit weg vom thema, aber was soll's. wenn ich es könnte würde ich auch die gross/kleinschreibung beachten. aber dem ist nicht so, ich brauch drei mal so viel zeit wenn ich mir über jedes wort gedanken machen ob es nun gross oder klein geschrieben wird und wüde dann immernoch fehler machen. da ne reine kleinschreibung (soviel ich weiss) dem lesefluss nicht behindert, seh ich bei derartigen plaudereien kein grund, dafür zeit zu verschwenden.