Validation Demo

Revision as of 11:31, 11 June 2026 by NeoWiki (talk | contribs) (Importing NeoWiki demo data)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

A live testbed for trying out NeoWiki's backend validation and seeing how the editor surfaces server-side errors next to each field.

Setup

Turn enforcement on in LocalSettings.php:

$wgNeoWikiEnforceValidation = true;

With this flag on, writes that introduce new violations are rejected with HTTP 422 and the editor renders the violations inline. With it off, writes always go through and the violations come back in the 200 response for informational purposes only.

Demo subjects

  • Validation Clean — a Subject with every property filled in correctly. Use it as the starting point for the recipes below.

The Validation Demo schema has four properties spanning the validation surface:

Property Type Notes
Title text, required A simple required text field.
Homepage url, required A single required URL. Empty triggers a "required" error inline.
Tags url, multi Optional list of URLs. Changing one entry to a non-http(s) URL triggers a per-entry invalid-url violation under enforcement; only the offending sub-input is decorated.
Status select, required A required choice between three options.

Recipes

See an inline error.

Open Validation Clean, switch to the Subjects tab, and click Edit on the main subject. Backspace the value in Title and click Save changes. The dialog stays open, the Title field gets a red border with "Please provide a value.", and a toast appears: Validation failed for "Validation Clean". Please fix the highlighted fields. The PUT in the network panel returns 422.

See the error clear as you type.

Trigger the inline error above, then type any character into the Title field. The red border disappears immediately, before you click Save again. The dialog wires the input back up to drop the matching server-side violation as soon as you edit.

See the success path still work.

Set $wgNeoWikiEnforceValidation = false and repeat the empty-Title save. The PUT now returns 200, the dialog closes, and the success toast fires. The 200 body still mentions the violation but it's advisory only — no inline marking, no rejection. This proves the step-1 contract from PR #855 still holds.

See a create-side error.

With enforcement on, click Add subject under "Other Subjects on this Page", choose Validation Demo, leave Title empty, and click Create subject. The create dialog behaves the same as the edit dialog: 422, dialog stays open, Title decorated, validation-failed toast.

See a per-entry error on a multi-value field.

With enforcement on, open Validation Clean → edit the main subject. Change the second Tags entry from https://example.com/b to ftp://example.com/b and click Save changes. Confirm: only the second sub-input gets the red border, the first stays clean. The 422 body carries valuePartIndex: 1, which the editor uses to target just that input.

Form-level banner.

This one is reachable only when a violation has no field anchor (e.g. schema-not-found, or a property removed from the schema after a Subject was saved). The component tests cover it; there's no clean UI reproduction against this schema. Verify in the test suite.

Backend wire shape

A 422 body from the persistence layer looks like:

{
  "status": "error",
  "message": "Validation failed",
  "violations": [
    { "propertyName": "Title", "code": "required", "args": [], "valuePartIndex": null }
  ]
}

The frontend parses this in RestSubjectRepository and throws a typed ValidationFailedError. Both SubjectEditorDialog and SubjectCreatorDialog catch it and feed the violations into the editor's reactive state. Each violation routes by propertyName (and valuePartIndex for multi-value inputs) to the matching field. Violations without an anchor fall into a form-level banner above the editor.

References