Abstrakte Wikipedia/Fehlermeldungen für ZObjects

This page is a translated version of the page Abstract Wikipedia/Error messages on ZObjects and the translation is 48% complete.

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äteren Aliasen 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 Revisionen, irgendwann ungültig werden - sonst könnten grundlegende Funktionen des Wikis, wie die Historie oder die Ansicht auf alte Revisionen, kaputt gehen.
  2. Die Überprüfung der Gültigkeit kann sehr teuer sein, insbesondere wenn wir die Gültigkeit mit benutzerdefinierten Typdefinitions- und Validierungsfunktionen überprüfen.

Hier ist ein Vorschlag zur Behebung des Problems:

  1. We introduce a new PHP class (probably similar to the current ZRecord) that holds a well-formed JSON-representation of any arbitrary ZObject, but is not a full blown PHP mirror of the type of that ZObject.
  2. Unless needed for the wiki to work, we don’t construct full PHP objects out of the ZObjects. Even the ZObjects that we need, we only construct them partially — the parts that we actually need for the wiki to work. Each of these PHP objects also has a member where it holds the well-formed JSON-representation of itself.
  3. Everything stored in the wiki is guaranteed to be well-formed and canonicalized.
  4. Everything stored in the wiki is guaranteed to follow the inalienable truths; these are hardcoded in the wiki and cannot be changed on wiki. These include that every object must be a Z2/Persistent object, that every Z2 has labels, etc.
  5. Both 3 and 4 are supposed to be stable-ish in the longer term.
  6. Beyond 3 and 4, we don’t do any other validation.
  7. When displaying stored or previewed content, we do validation, and display the errors.
  8. Before storing, the contributor can either preview, or call validation, or validation is called automatically, and the contributor will see a list of errors. The “publish” button might be grayed out or not displayed if there are errors.
  9. But once the API gets invoked to store, we will do so even in face of validation errors — but not in face of well-formedness errors or errors against inalienable truths.
  10. Invalid ZObjects *always* use the generic viewer and editor, not the specific one (as the requirements for the specific viewer might be violated).
  11. The generic viewer also shows a list of all validation errors if any.

Siehe auch