4 · Daten

Eine Datenart heißt Model. Sie wird groß geschrieben, ihre Felder stehen eingerückt darunter.

modell Beitrag
  titel   text
  inhalt  langtext
  bild    bild optional
  gelesen zahl = 0
  am      zeit = jetzt
  autor   Nutzer = ich

Ein Feld ist: Name, Typ, dann wahlweise optional und eine Vorgabe.

Feldtypen

email ist ein Textfeld, das der Browser als Adressfeld behandelt — und am Nutzer-Model bedeutet es mehr: Dort schaltet es den Rückweg per Post frei, also „Passwort vergessen" mit einem zugeschickten Code. Das steht in 05 · Daten und Rechte.

bild und datei laden sofort hoch, sobald man etwas auswählt. Im Datensatz steht danach nur die Adresse. Erlaubt sind PNG, JPEG, GIF, WEBP, AVIF und PDF — erkannt an den ersten Bytes, nicht am Dateinamen. SVG ist nicht erlaubt: darin darf JavaScript stehen, und das liefe dann unter deiner Adresse.

Zur unterschrift ein Wort, weil es sonst falsche Erwartungen weckt: eine mit dem Finger gemalte Unterschrift ist eine einfache elektronische Signatur. Für einen Übergabebeleg oder eine Empfangsbestätigung reicht das gut. Für Verträge, die gesetzlich Schriftform verlangen, reicht sie nicht.

optional

Ohne optional muss ein Feld gefüllt werden. Das Formular verlangt es, und der Server nimmt es sonst nicht an.

  hinweis text optional

auswahl — feste Werte statt freiem Text

Die erlaubten Werte stehen hinter dem Typ:

modell Nutzer
  name  text
  rolle auswahl "kunde" "verwalter" = "kunde"

Im Formular wird daraus eine Aufklappliste. Ohne Vorgabe steht dort zuerst eine leere Zeile — ein Pflichtfeld, das von sich aus den ersten Wert zeigt, wird sonst abgeschickt, ohne dass jemand gewählt hat.

Drei Dinge kommen dazu, und der dritte ist der eigentliche Grund für diesen Typ:

1. Der Server nimmt nichts anderes an. Ein Formular ist nur ein POST; wer es nachbaut, schreibt hinein, was er will. Bei text wäre "verwalter" einen Handgriff entfernt.
2. fibel prüfe merkt, wenn die Vorgabe nicht dabeisteht.
3. Ein Tippfehler im Vergleich fällt auf. Das hier

   seite /verwaltung
     nur ich.rolle == "verwalger"

ist eine gültige Bedingung — sie trifft nur nie zu, und niemand merkt es. Weil das Model die Werte kennt, ist es beim Prüfen ein Fehler:

   Zeile 12: "verwalger" ist kein Wert von ich.rolle
             erlaubt: "kunde", "verwalter"

Geprüft wird das überall, wo eine Bedingung steht: in nur, in sichtbar und aenderbar, in wenn und in wo.

Was auswahl nicht ist: eine Liste, die sich zur Laufzeit ändert. Wer Werte pflegen will, nimmt ein eigenes Model und einen Verweis darauf.

Vorgaben

  am     zeit = jetzt        # der Moment des Anlegens
  autor  Nutzer = ich        # wer gerade angemeldet ist
  rolle  text = "kunde"      # ein fester Text
  vorrat zahl = 0

= ich ist mehr als eine Bequemlichkeit: dieses Feld kommt immer aus der Sitzung und lässt sich über kein Formular setzen. Wer versucht, es mitzuschicken, wird ignoriert. Nur so trägt es die Eigentümer-Regel aus Anmeldung und Rechte.

Verweise zwischen Models

modell Kommentar
  beitrag Beitrag
  inhalt  langtext
  von     Nutzer = ich

Im Programm greift man dann durch:

fuer kommentar in Kommentar wo kommentar.beitrag == beitrag
  karte
    text kommentar.inhalt
    hinweis "von " kommentar.von.name

festgeschrieben

modell Zustellung
  sendung      Sendung
  ergebnis     text
  unterschrift unterschrift optional
  am           zeit = jetzt
  fahrer       Nutzer = ich
  festgeschrieben

Ein festgeschriebenes Model lässt sich nach dem Anlegen nicht mehr ändern und nicht löschen — auch nicht von dem, der es angelegt hat. Ein formular ändere darauf meldet die Prüfung als Fehler.

Gedacht für alles, was als Nachweis dienen soll: eine Empfangsbestätigung, ein Arbeitsbericht, ein Protokolleintrag. Eine Unterschrift, die man hinterher noch ändern kann, ist als Nachweis nichts wert.

sichtbar

modell Nachricht
  an    Nutzer
  von   Nutzer = ich
  text  langtext
  sichtbar eintrag.an == ich oder eintrag.von == ich

Das ist ein Leserecht am einzelnen Datensatz. Ausführlich im nächsten Kapitel.

Das Model Nutzer

Ein Model namens Nutzer (oder User) ist besonders: seine Existenz schaltet die Anmeldung frei und macht ich verfügbar.

modell Nutzer
  name  text
  bild  bild optional
  rolle text = "kunde"

Passwörter stehen nicht in diesem Model. Sie liegen als scrypt-Hash in einer eigenen Datei neben der App, mit eigenem Salz je Konto. Wer die Datendatei in die Hände bekommt, hat keine Passwörter.

Wo die Daten liegen

Neben der .fibel-Datei:

Alle drei gehören in keine Versionsverwaltung; die mitgelieferte .gitignore kennt sie schon.

Eine neue App legt ihre Daten in SQLite ab. Die JSON-Datei gibt es weiter für Apps, die schon eine haben — sie liest und schreibt bei jeder Änderung die ganze Datei, was für eine Handvoll Nutzer gut geht und für einen echten Shop nicht. Wie man umzieht, steht in Ausliefern.

Aufräumen

fibel aufräumen meine-app

Entfernt hochgeladene Dateien, auf die kein Datensatz mehr zeigt. Ohne das wachsen sie ewig.

Weiter: Anmeldung und Rechte