Wikipédia abstraite/Messages d’erreur sur les Z-Objets
Appearance
Projet Phabricator : #abstract wikipedia
Actuellement, nous évaluons, construisons et validons un Z-Objet tout entier au sein du code PHP de l’extension WikiLambda à partir de la sérialisation JSON stockée dans le wiki.
Il y a deux principales raisons pour cela :
- Cela valide la sérialisation JSON : si la sérialisation ne représente pas un objet valide, la construction de l’objet échouera. De cette façon nous évitons que du contenu non valide entre dans le wiki, ce qui signifie que nous pouvons traiter tout contenu comme valide et supposer que certaines conditions sont remplies.
- Pour certaines des tâches que le wiki a besoin de réaliser, telles que l’obtention de libellés, plus tard des alias, et certaines des vues spécifiques sur le wiki, l’objet *doit* remplir certaines conditions, sinon le wiki ne peut en fait pas fournir certaines fonctionnalités fondamentales, telles que la recherche ou l’affichage.
Ceci a un certain nombre d’inconvénients :
- Nous escomptons que la plupart des contenus du wiki, y compris ses types et validations, soit éventuellement modifiable par la communauté. Ceci signifie que ce qui est valide et ce qui ne l’est pas changera au cours du temps, et que ce qui était valide à un instant donné peut ne plus l’être à un autre. Il nous faut tenir compte du contenu non valide car le contenu, au moins dans une version plus ancienne, pourrait devenir finalement non valide — sinon les fonctionnalités de base du wiki, comme l’historique ou la vue des anciennes versions, pourraient être rompues.
- La vérification de validité peut être très coûteuse, notamment si nous vérifions la validité en utilisant les définitions de type et les fonctions de validation fournies par les utilisateurs.
Voici une suggestion pour remédier au problème :
- Nous introduisons une nouvelle classe PHP (probablement similaire à l’actuel ZRecord) qui conserve une représentation JSON bien formée de tout Z-Objet arbitraire, mais qui n’est pas un miroir PHP à part entière du type de ce Z-Objet.
- À moins que ce ne soit nécessaire pour faire fonctionner le wiki, nous ne construisons pas des objets PHP complets depuis les Z-Objets. Même pour les Z-Objets dont nous avons besoin, nous ne les construisons que partiellement — seulement les parties dont nous avons besoin pour faire fonctionner le wiki. Chacun de ces objets PHP a également un membre qui conserve la représentation JSON bien formée de lui-même.
- Tout ce qui est stocké dans le wiki est garanti d’être bien formé et dans sa forme canonique.
- Tout ce qui est stocké dans le wiki est garanti de suivre les vérités inaliénables ; celles-ci sont codées en dur dans le wiki et ne peuvent pas être modifiées sur le wiki. Celles-ci incluent que tout objet doit être un Z2/Objet persistant, que chaque Z2 a des libellés, etc.
- Les points 3 et 4 sont tous deux supposés rester relativement stables à long terme.
- Au delà des points 3 et 4, nous ne faisons pas d’autre validation.
- Lors de l’affichage de contenu stocké ou prévisualisé, nous effectuons la validation et affichons les erreurs.
- Avant de confirmer le stockage, le contributeur peut soit prévisualiser, soit appeler la validation, ou la validation est appelée automatiquement, et le contributeur verra une liste des erreurs. Le bouton « Publier » pourrait être grisé ou non affiché s’il y a des erreurs.
- Mais une fois que l’API est invoquée pour effectuer le stockage, nous le ferons même face à des erreurs de validation — mais pas face à des erreurs de contenu mal formé ou des erreurs de violation des vérités inaliénables.
- Les Z-Objets non valides utilisent *toujours* la visionneuse et l’éditeur génériques, pas des versions spécifiques (puisque les prérequis pour une visionneuse spécifique à un type d’objet peuvent être violés).
- La visionneuse générique montre également une liste de toutes les erreurs de validation s’il y en a.