TVTower / TVTDatabaseEditor

Xtext-Based editor for the database files
Eclipse Public License 2.0
0 stars 1 forks source link

Thread-ID bei Nachrichten #5

Closed nittka closed 3 years ago

nittka commented 3 years ago

Nachrichten können andere Nachrichten anstoßen und es kann ihnen eine entsprechende "threadID" gegeben werden. Im aktuellen Datenbestand haben manche Nachrichtenketten eine solche ID, andere nicht. Am "schönsten" wäre natürlich, wenn solche Nachrichtenketten under einem "thread"-Knoten hängen würden und nicht alle auf der Top-Level-Ebene liegen würden. Um aber große Umbauarbeiten zu vermeiden wäre mein Vorschlag wie folgt.

Diese Validierung erfolgt nicht in TVTower, sondern in diesem Editor (Konsistenzprüfung, Best Practice)

GWRon commented 3 years ago

Also ... Die Frage ist: warum sollen Nachrichten nur "eigene" Thread-Nachrichten triggern?

Die Idee ist: "Viele Wege fuehren nach Rom". Eine Politiker-Skandalnachricht koennte von sich aus gestartet werden. Oder von einer Nachrichtenkette. Sie koennte aber auch durch die Enthuellung eines Schauspielers getriggert werden. Wir haben also verschiedene Nachrichtenketten die bspweise "beilaeufig" eine bestimmte Nachricht triggern koennten - und auch den Zufall der das kann.

Auch aus diesem Grund sind die Nachrichten alle vom selben "Nesting-Level".

Welchen Vorteil siehst Du denn noch in der threadID - ausser der "Gruppierung"?

nittka commented 3 years ago

Wenn es prinzipiell gewünscht ist, dass jede Nachricht jede andere triggern könnte, wozu dann überhaupt eine threadID? Um Nachrichten in der XML-Datei als zusammengehörig zu erkennen, würde auch räumliche Nähe und ein Kommentar ausreichen. Ein Property der Art "Du kannst hier alles eintragen, es spielt überhaupt keine Rolle; es ist vorrangig dafür da, Dich zu verwirren und wird an keiner Stelle für irgendetwas verwendet" erscheint nicht sinnvoll.

Ich würde im Zuge der Aufräumaktion gern erreichen, dass für Neulinge dokumentiert ist, welche Eigenschaften was bedeuten (wie die Wertebereiche sind und was verpflichtend angegeben werden muss). Und je klarer die Ansagen und je weniger Überflüssiges übrig bleibt desto besser.

Ggf. ist das Ergebnis ja auch, dass es bzgl. threadID beim aktuellen Stand bleibt. Den Mehrwert, den ich für das Einführen noch nicht vorhandener IDs sehe ist, dass man in einem Editor die Nachrichten tatsächlich (z.B. im Outline) gruppieren könnte. Dann sieht man viel schneller, was zusammengehört. Und es muss ja kein Fehler sein, wenn was anderes getriggert wird, sondern ggf. nur eine Warnung - Hinweis, dass man die falsche Nachrichten-ID eingetragen hat.

GWRon commented 3 years ago

Die threadid wurde nicht von mir eingefuehrt.

Auch hast Du ja ein Argument fuer die ThreadID genannt: visuelle Gruppierbarkeit in Editoren.

Ich finde nur die Einschraenkung "nur News mit gleicher threadID koennen sich triggern" nicht notwendig

Fuer Editoren ist sie nicht unbedingt notwendig...da ja A B triggern kann aber D vlt auch B ohne A zu kennen. In einer Editoruebersicht/liste koennten alle getriggerten unterhalb des Triggerelements gelistet werden (also evtl mehrfach) oder einfach alphabetisch. ThreadID waere hier wie erwaehnt nur der Gruppenindikator (als dritte Darstellungsoption).

nittka commented 3 years ago

Thread-ID ist informativ. Ich warne, wenn Nachrichten aus einem anderen Thread angestoßen werden.