Editor und Synchronisation
Worum geht es?
Kurz gesagt: Dein Text liegt als strukturierter Baum vor und nicht als lose Zeichen. Szenen leiten wir auf dem Server aus diesem Text ab, und jede Änderung trägt eine Version, damit Konflikte auffallen. So bleiben Text und Szenen-Daten zusammen, auch wenn mehrere Personen und Geräte beteiligt sind.
Schutzziel
Text und die Daten, die daran hängen, sollen nicht auseinanderlaufen. Keine Änderung soll eine andere still überschreiben, und Kommentare sollen an ihrer Textstelle bleiben.
Funktionsprinzip
- Strukturierter Text: Der Editor (TipTap) arbeitet mit einem Baum aus Bausteinen und nicht mit rohem HTML. Das macht ihn prüfbar und erlaubt Verweise im Text.
- Szenen aus dem Text: Der Szenentrenner im Text ist die einzige Quelle. Der Server leitet die Szenen-Daten beim Speichern daraus ab, in derselben Transaktion wie die Versionsprüfung. Die Oberfläche führt keine zweite, eigene Szenenliste.
- Szenen bleiben erhalten: Verschwindet ein Trenner aus dem Text, wird die Szene nur als gelöscht markiert. Verknüpfte Daten wie Hinweise oder Figuren-Zuordnungen gehen nicht verloren, und stellst du den Trenner wieder her, kehrt die Szene zurück.
- Versionen: Jedes Speichern nennt den Stand, auf dem es aufbaut. Weicht er vom Stand auf dem Server ab, meldet der Server einen Konflikt, und du entscheidest im Konfliktdialog.
- Erwähnungen: Figuren, Orte und andere Einträge stehen im Text als Verweis auf den Eintrag und nicht als bloßer Name. Wird ein Eintrag umbenannt, folgt der Text, außer du hast bewusst einen Decknamen gewählt.
- Kommentare: Sie hängen an einer Markierung im Text und nicht an einer Zeichenposition. Geht die Markierung verloren, hilft ein gespeicherter Textausschnitt, die Stelle wiederzufinden.
- Kapitel beanspruchen: Wer ein Kapitel bearbeitet, kann es als „in Bearbeitung“ markieren. Andere sehen den Hinweis.
Maßnahmen
- Wir leiten Szenen auf dem Server ab, damit Oberfläche, Offline-Stand und Datenbank nicht auseinanderlaufen.
- Wir lehnen ein Speichern mit veraltetem Stand ab, statt die neuere Fassung stillschweigend zu verdrängen.
- Wir verschmelzen nicht automatisch. Bei einem Konflikt wählst du, so geht keine Offline-Arbeit unbemerkt verloren.
- Wir verwenden feste Kennungen für Erwähnungen, damit Umbenennungen nichts brechen.
- Der Text wird beim Speichern geprüft und auf eine Erlaubtliste begrenzt.
Was wir nicht versprechen
- Es gibt kein gleichzeitiges Schreiben im selben Absatz wie in Echtzeit-Editoren. Bei einem Konflikt entscheidest du.
- Das Beanspruchen eines Kapitels ist ein Hinweis, der Konflikte vermeiden hilft, und keine Gewähr, dass niemand sonst schreibt.
- Ein Kommentar kann seine Textstelle verlieren, wenn der Text dort stark umgebaut wird. Dann hilft der Textausschnitt, aber er findet nicht in jedem Fall die richtige Stelle.
Wie wir das prüfen
Die Ableitung der Szenen, das gleichzeitige Speichern und das Beanspruchen von Kapiteln haben automatisierte Tests, die die Tabelle unten nennt. Das Szenario „Race Conditions“ steht im Monatsbericht.
Nachweis-Tests
| Test | Das belegt der Test |
|---|---|
ChapterContentSyncServiceTest |
Szenen werden auf dem Server aus dem eingereichten Text abgeleitet. |
ChapterContentSaveRaceConditionTest |
Gleichzeitiges Speichern desselben Kapitels überschreibt nichts still. |
ChapterContentAstSecurityTest |
Präparierte oder zu große Texte werden abgelehnt, ohne Spuren zu hinterlassen. |
ChapterClaimTest |
Ein Kapitel lässt sich als „in Bearbeitung“ beanspruchen. |
ChapterClaimRaceConditionTest |
Beanspruchen zwei Nutzer gleichzeitig dasselbe freie Kapitel, gewinnt nur einer. |
MentionAstIntegrityTest |
Erwähnungen im Text bleiben gültige Verweise auf ihre Einträge. |
Änderungsverlauf
- : Erste Fassung.