Junker: Undo/Redo - wie Änderungen serverseitig pflegen?

guten Abend :)

bin grad am überlegen, wie ich eine undo/redo-Funktion in mein Programm bauen könnte. Clientseitig ist mit Javascript alles wunderbar: Ich speichere den Status vor der Änderung, ändere dann Daten, bzw. der User ändert die Daten. Falls er das alles nicht gewollt hatte, kann er durch einen "Undo/Redo"-Click den alten Stand wiederherstellen.

Wie werden die Daten aber an den Server weitergegeben? Sofort nach Ändern der Daten einen AJAX-Aufruf, um die Änderung zu speichern. Wenn dann die Änderung rückgängig gemacht werden soll, einen zweiten AJAX-Aufruf, welcher die alten Daten recycelt und neu an den Server sendet?
Oder den AJAX-Aufruf mit den neuen Daten für eine bestimmte Zeit (z.B. 5 Sekunden) zurückhalten, da der Anwender seinen Fehler oftmals sofort nach der Änderung bemerkt. Was ist aber, wenn er sofort nach der Änderung wegnavigiert, es einen Client-Fehler gibt?

Vielleicht habt ihr schon mal Erfahrungen mit sowas gesammelt, wenn nicht, interessiert mich eure Meinung :)

Geruhsamen Abend,

Junker

  1. Moin,

    Tags: Revision Control System, Repository

    Ein Request schickt die Daten zum Server, dort erfahren die Daten ein checkin. Clientseitig gibt es die Möglichkeit (administrative), das Deployment zu kontrollieren, d.h., aus der Repository eine bestimmte Version deployen zu können.

    Horst Henner

    --
    Ein Laden der laufen soll, braucht keine Klugscheiser sondern zahlungswillige Kunden.
  2. Hello,

    Vielleicht habt ihr schon mal Erfahrungen mit sowas gesammelt, wenn nicht, interessiert mich eure Meinung :)

    Aus ganz verschiedenen Gründen (rechtlich, fachlich) kann es sinnvoll sein, die Daten in der Datenbank zu historisieren (Stichwort "history tables"), d.h. im Falle von Änderungen den Datensatz im vorherigen Zustand aufzubewahren. Manche Datenbanken, zum Beispiel IBM DB2, unterstützen ab Werk temporal tables. Das Konzept ist für dich vielleicht auf den ersten Blick etwas überdimensioniert, würde es dir aber ermöglichen auf dem Server die vorherige Version explizit wiederherzustellen. Im Unterschied zu einer in-memory Lösung wäre auch im Fall eines Abbruchs der Session der neue UND der alte Zustand persistiert. Alternativ gilt natürlich das von hotti vorgeschlagene Konzept der expliziten Freischaltung.

    MfG
    Rouven

    --
    -------------------
    sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
    Sometimes you're ahead, sometimes you're behind. The race is long and, in the end, it's only with yourself.  --  Mary Schmich (Chicago Tribune; 1997); Baz Luhrmann (1999), see http://en.wikipedia.org/wiki/Wear_Sunscreen