[php] Sessions und Browserfenster bzw. Tabs

[Tobias Daur]

Hi Lutz,

erstmal danke für die Mühe die Du Dir machst (und danke für die
vorab-neugierigmach-pm ;)).

> Wir haben uns etwas verzettelt und drehen uns im Kreis, weil vermutlich 
> den meisten - bis heute Morgen einschließlich mir - nicht in Gänze klar 
> ist, worum es Dir praktisch geht. Es fehlt so ein Bißchen der 

Jo, da sieht man mal wieder, wie kompliziert zwischenmenschliche
Kommunikation ist :)


Dein Ansatz bietet, soweit ich das ausprobiert habe, tatsächlich einen
Überschreibschutz, der auch bei mehreren Fenstern/Tabs zuverlässig
funktioniert. Und das ohne die Übergabe von Werten - bis auf die ID und
die Session (Cookie) natürlich. 
Mit der Session-Variable stellst Du sicher, daß nur der Browser mit
dieser Session schreiben kann. Daß er es nur mit dem richtigen Fenster
kann, machst Du einfach darüber, daß Du einen Zweitaufruf während der
Bearbeitungszeit verhinderst. 

Was mir daran nicht so gefällt:
Du identifizierst nicht wirklich den richtigen Tab/das richtige Fenster.
Deshalb kann bei Deinem Skript auch das eigene (bearbeitende) Fenster
nicht neu geladen werden - der Reload wird blockiert.
Außerdem begrenzt der Schutz stark die praktische Anwendung, denn Du
+ zwingst den Anwender zu einer Bearbeitung innerhalb einer bestimmten
Zeit
+ fängst Fälle ab, die gar nicht zu einer Kollision führen,
beispielsweise wenn nur einer der Bearbeiter wirklich speichert.

Damit machen wir aber ein zweites Faß auf. 

Faß 1: Wie realisiert man Sessions garantiert fenster/tab-bezogen? 
Das ist wieder allgemein gesprochen das Thema: Sessions identifizieren
einen Compi/Anwender. Zur Anwendungssteuerung braucht man aber IMHO
einen Mechanismus, der ein Fenster identifiziert. 

Faß 2: Wie macht man einen 100% funktionierenden Kollisionsschutz, der
die Arbeit möglichst wenig behindert. 

Um mal das zweite Faß zu beackern, denn darauf zielen ja die Punkte ab,
die mir bei Deinem Modell nicht so gefallen (hmm, muß man jetzt einen
neuen Betreff setzen?):

Ein Kollisionsschutz sollte
+ nicht zeitbasiert sein (trotz zustandslosem Protokoll)
+ nur bei einer echten Kollision greifen

Und genau dies leistet folgendes Modell:
+ jeder Datensatz bekommt einen timestamp
+ geprüft wird ausschließlich beim Schreiben
Wenn's knallt, gibt das Skript ein Diff aus, mit der Möglichkeit, die
beiden Datensätze zu vergleichen und einen korrekten zu speichern.

Wenn ich mich nicht irre, ist das auch in etwa das, was cvs macht, oder?

In der Edelversion wird dann auch noch ausgegeben, wie der Datensatz
aussah, bevor er von einem anderen Fenster/User geändert wurde. Dazu muß
man sich den DS vor dem Ändern in der tab/fenstersicheren Session
wegspeichern. 

Und so möchte ich den Kollisionsschutz eigentlich auch bauen - nur mit
dem von mir in meiner letzten Mail beschriebenen Problem, das entsteht,
wenn ich den timestamp in der Session zwischenspeichere und einen
zweiten Tab aufmache. 

Das Problem beim Konstruieren einer tabsicheren Session scheint ja der
Moment zu sein, in dem man einen Tab dupliziert. 
Wenn man einfach mit einem zweiten Tab auf die Site geht und lossurft,
kann man das ja, wie Sebastian es vorschlägt, über eine zufällig
generierte Formular-ID in der Session speichern - dann hätte dasselbe
Formular mit dem selben Datensatz, zweimal aufgerufen, einen getrennten
Eintrag in der Session. 
Nur in dem einen Fall, in dem man einen Tab mit einem Formular soeben
dupliziert hat, sind's dieselben. Vielleicht muß man den Fall einfach
vernachlässigen (womit ich mir selber widerspreche ;)).

Aber ich schreibe schon wieder Romane ...


danke fürs lesen

Tobias

-- 
Tobias Daur :: daur at gmx.de