Formulieren die zichzelf schrijven vanuit hetzelfde schema

Een formulier is meestal het meest tijdrovende onderdeel van het bouwen van een admin: het juiste invoer per veld, client- en servervalidatie die synchroon blijft, en een aanmaakformulier en een bewerkingsformulier die in de loop van de tijd stilletjes van elkaar afdrijven. In Phlo lezen het aanmaakformulier, het bewerkingsformulier, de lijstweergave en de REST API allemaal exact hetzelfde schema, dus er is maar één plek waar dat van kan afwijken.

De invoer volgt het type

static schema => arr(
    status:  field(type: 'select', options: ['draft', 'sent', 'paid']),
    notes:   field(type: 'text', multiline: true),
    cover:   field(type: 'image'),
    sent_at: field(type: 'datetime'),
)

Een select rendert een dropdown die beperkt is tot de gedeclareerde opties, text met multiline: true rendert een textarea in plaats van een enkele regel invoer, image rendert een uploadcontrole met een thumbnail preview, datetime rendert de bijbehorende picker. Dit is niet per formulier geschreven; elk veldtype resource (fields/select, fields/image, enzovoort) heeft zijn eigen input() rendering, en het CMS vraagt gewoon het schema welke veldtype een bepaalde kolom bezit.

Validatie voordat het ooit de database bereikt

Een model optioneel maken met static objValidate = true voert de bijbehorende objValidate($value) uit voor elk veld in het schema voordat create() iets vastlegt, een pattern: of enum: beperking die op het veld is gedeclareerd is dezelfde regel die het aanmaakformulier en de aanmaak API afdwingen, omdat beide in hetzelfde veldobject aanroepen:

if (!user::create($args)) return apply(errors: user::objErrors())

required: true gaat verder en wordt uniform gecontroleerd bij zowel aanmaken als bewerken; de rest van objValidate is vandaag de dag een poort voor het aanmaken. Hoe dan ook, er is geen aparte client-side validatiebibliotheek om in sync te blijven met een server-side regel die eenmaal is geschreven en vervolgens stilletjes op de frontend is vergeten.

CSRF, standaard

Elke schrijfoperatie, POST, PUT, PATCH, DELETE, is CSRF-beschermd zonder extra configuratie van de ontwikkelaar. Dit is niet zozeer een functie die specifiek is voor formulieren, maar eerder een gevolg van het feit dat het schrijfpad één gedeeld mechanisme is in plaats van één per model: beveilig het mechanisme eenmaal, en elk model dat erdoorheen gaat, erft automatisch de bescherming.

Het daadwerkelijke opslaan

Dit alles gaat niet over het feit dat een enkel formulier er mooi uitziet. Het is zo dat een schemawijziging, het toevoegen van een veld, het aanscherpen van een validatieregel, het wijzigen van een invoertype, de lijstweergave bijwerkt, zowel formulieren als de API tegelijk, omdat er altijd maar één beschrijving van het model was om te wijzigen.