Abstrakte Wikipedia/Fehlermeldungen für ZObjekte

Derzeit wird das gesamte ZObjekt innerhalb des PHP-Codes der WikiLambda-Erweiterung aus der im Wiki gespeicherten JSON-Serialisierung ausgewertet, konstruiert und validiert.

Dafür gibt es zwei Hauptgründe:

1. Es validiert die JSON-Serialisierung: Wenn die Serialisierung kein gültiges Objekt darstellt, schlägt die Objektkonstruktion fehl. Auf diese Weise verhindern wir, dass ungültige Inhalte in das Wiki gelangen. Dies bedeutet, dass wir alle Inhalte als gültig behandeln und davon ausgehen können, dass bestimmte Bedingungen erfüllt sind.
2. Für einige der Aufgaben, die das Wiki ausführen muss, wie z. B. das Abrufen von Bezeichnungen, später Aliassen und einigen der spezifischen Ansichten im Wiki, *muss* das Objekt bestimmte Bedingungen erfüllen, sonst kann das Wiki bestimmte grundlegende Funktionen, wie z. B. die Suche oder die Anzeige, gar nicht bereitstellen.

Dies hat eine Reihe von Nachteilen:

1. Wir erwarten, dass der größte Teil des Wikis, einschließlich der Typen und Validierungen, schließlich von der Community bearbeitet werden kann. Das bedeutet, dass sich das, was gültig ist und was nicht, im Laufe der Zeit ändert, und was zu einem bestimmten Zeitpunkt gültig war, ist es zu einem anderen Zeitpunkt möglicherweise nicht mehr. Wir müssen mit ungültigen Inhalten zurechtkommen, weil Inhalte, zumindest in älteren Versionen, irgendwann ungültig werden — sonst könnten grundlegende Funktionen des Wikis, wie die Versionsgeschichte oder die Ansicht alter Versionen, kaputt gehen.
2. Die Überprüfung der Gültigkeit kann sehr aufwendig sein, insbesondere wenn wir die Gültigkeit mit benutzerdefinierten Typdefinitions- und Validierungsfunktionen überprüfen.

Hier ist ein Vorschlag zur Behebung des Problems:

1. Wir führen eine neue PHP-Klasse ein (wahrscheinlich ähnlich wie die aktuelle ZRecord), die eine gut geformte JSON-Darstellung eines beliebigen ZObjektes enthält, aber kein vollständiger PHP-Spiegel vom Typ des ZObjektes ist.
2. Sofern es nicht nötig ist, damit das Wiki funktioniert, konstruieren wir aus den ZObjekten keine vollständigen PHP-Objekte. Selbst die ZObjekte, die wir benötigen, konstruieren wir nur teilweise — nur die Teile, die wir benötigen, damit das Wiki funktioniert. Jedes dieser PHP-Objekte hat auch ein Mitglied, in dem sich die gut geformte JSON-Darstellung von sich selbst befindet.
3. Es ist garantiert, dass alles, was im Wiki gespeichert ist, gut geformt und kanonisch ist.
4. Es ist garantiert, dass alles, was im Wiki gespeichert ist, die unveräußerlichen Wahrheiten befolgt; diese sind im Wiki hartcodiert und können im Wiki nicht geändert werden. Dazu zählt, dass jedes Objekt ein Z2/Persistentes Objekt sein muss, dass jedes Z3 Bezeichnungen hat, etc.
5. Sowohl 3 als auch 4 sollen langfristig stabil sein.
6. Über 3 und 4 hinaus führen wir keine anderen Validierungen durch.
7. Wenn gespeicherter oder in der Vorschau befindlicher Inhalt angezeigt wird, führen wir eine Validierung durch und zeigen die Fehler an.
8. Vor dem Speichern kann der Benutzer sich die Vorschau ansehen, eine Validierung durchführen lassen oder die Validierung wird automatisch durchgeführt und der Benutzer erhält eine Liste der Fehler. Die Schaltfläche “Veröffentlichen” kann ausgegraut sein oder wird nicht angezeigt, wenn es Fehler gibt.
9. Wenn die API zur Speicherung aufgerufen wird, wird diese auch dann erfolgen, wenn es Validierungsfehler gibt — jedoch nicht, wenn Fehler bei der guten Formung oder Verstöße gegen die unveräußerlichen Wahrheiten vorliegen.
10. Ungültige ZObjekte nutzen *immer* die generische Ansicht und den generischen Editor, nicht den spezifischen (da möglicherweise gegen die Anforderungen für die spezifische Ansicht verstoßen wird).
11. Bei der generischen Ansicht wird auch eine Liste aller Validierungsfehler angezeigt, sofern welche vorliegen.

Siehe auch

• Übersicht der Anmerkungen