Abstrakta Wikipedia/Fejlmeddelelser på ZObjekter

Currently, we evaluate, construct, and validate the entire ZObject within the PHP code of the WikiLambda extension from the JSON serialization stored in the wiki.

There are two main reasons for that:

1. It validates the JSON serialization: if the serialization does not represent a valid object, the object construction will fail. This way we prevent invalid content from entering the wiki, which means we can treat all content as valid and may assume that certain conditions hold.
2. For some of the tasks the wiki needs to perform, such as getting labels, later aliases, and some of the specific views on the wiki, the object *has* to fulfill certain conditions, or else the wiki cannot actually provide certain fundamental features, such as search or display.

This has a number of drawbacks:

1. We expect most of the wiki, including its types and validations, to eventually be editable by the community. This means that what is valid and what is not will change over time, and what was valid at some point might not be at another point. We need to cope with invalid content, because content, at least in older revision, will ultimately become invalid — otherwise basic features of the wiki, just as history or view on old revisions may break.
2. Checking validity can be very expensive, especially if we check the validity using user-provided type definition and validation functions.

Here is a suggestion to remedy the issue:

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.

Se også

• Oversigt over notater