Expand validation options: implementation approach and severity levels#631
Expand validation options: implementation approach and severity levels#631alistair3149 wants to merge 2 commits intomasterfrom
Conversation
alistair3149
force-pushed
the
validation-option-3
branch
from
0b1bc9a to
f09ff4c
Compare
In option 3, the document mentions that the same constraint metadata could drive the Schema Editor UI. Some more detail on that thought: Currently, each Property Type has a hand-coded If constraints are declared as metadata (which Option 3's generic interpreter already requires), the same metadata could describe the editor UI: what control type to render, grouping, visibility rules. A generic renderer would replace per-type components, so adding a new Property Type or constraint wouldn't require writing a new Vue component — just a metadata declaration. This becomes more valuable as the number of Property Types grows, and especially if third-party extensions define their own types via the plugin system. Written by Claude Code, Opus 4.6. Result of back and forth with @alistair3149 exploring the validation architecture. |
alistair3149
force-pushed
the
validation-option-3
branch
from
f09ff4c to
0a831b7
Compare
alistair3149
changed the title
| Pros: | ||
| * API users can edit Subjects without prior validation without risking creating "invalid" Subjects | ||
| * API users can potentially validate Subjects without editing via a new dedicated endpoint | ||
| * The Schema remains the single source of truth for rules. Interpreters are generic and stable. |
There was a problem hiding this comment.
This is not a pro of this approach. I'm guessing these additions are AI-generated?
There was a problem hiding this comment.
It is considered a pro because the validation rules are only defined with the schema.
The single source of truth approach makes validation more maintainable and simpler.
There was a problem hiding this comment.
That's a pro of having a single source of truth, but if we don't have backend validation, then we also have a single source of truth, so this is not a pro of adding backend validation, it's just something that does not regress.
There was a problem hiding this comment.
I have restructured the document to make it more clear.
alistair3149
force-pushed
the
validation-option-3
branch
from
0a831b7 to
112f44c
Compare
Adds a third option to the Validation Architecture document. This option introduces user-defined severity levels (warning vs error) on Schema constraints, with the Schema as the single source of truth and generic constraint interpreters in both TS and PHP for instant feedback. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reframe Option 3 as "both frontend and backend validation" with the generic interpreter approach. Move severity levels to a separate document as an independent concern. Distribute shared pros across options that have them instead of mirroring as cons. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
alistair3149
force-pushed
the
validation-option-3
branch
from
112f44c to
892f731
Compare
2 participants
Summary
and single source of truth
Test plan
Written by Claude Code, Opus 4.6. Result of extensive back and forth with @alistair3149.
Context: the NeoWiki codebase and existing Validation Architecture document.
Generated with Claude Code