_roro: Workaround

Beitrag lesen

Prüfung und Datenhaltung serverseitig, klaro.
Aber zum Bearbeiten werden die Daten auf einen CLient geholt. Auch der timestamp. Es ist nur eine Frage, _wo_ der timestamp, der für den Bearbeiter von untergeordneter Bedeutung ist, clientseitig gespeichert werden soll.

Dieser timestamp, der bewirkt, dass später dem "Zweiteditierer" die Meldung erscheint "Ersteditierer hat Datensatz nach dem Laden des Datensatzes durch Sie Herr Zweiteditierer aktualisiert, wollen Sie die Daten des Ersteditierers (werden ggf. angezeigt) überschreiben?", was macht der denn beim Client???

Natürlich kann ich _den_ timestamp auch serverseitig halten, brauche dazu jedoch einen Mechanismus, der den Client identifiziert, damit die Zuordnung auf dem Server stimmt. Auch wenn ich diesem Mechanismus schon habe (bspw. AuthBasic oder Session-Cookie), warum sollte ich dieses Verfahren so verumständlichen? Eine extra Repository auf dem Server zu halten, wo drinsteht, wer wann welchen Record in seinen Browser geladen hat?

Schön und gut, wenn das so gewünscht wird, kann ich das machen, selbstverständlich, ja.

Aber es war nicht so gewünscht und wenn der Client ohnehin einen Datensatz lokal zu sich in den Browser holt, kriegt er auch den timestamp der letzen Bearbeitung mit.

roro